Hi Rowan, This message is in reply to https://externals.io/message/125455#125496 from the thread "bikeshed: Typed Aliases"
> On Sep 10, 2024, at 5:35 PM, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> > wrote: > On 10 September 2024 19:32:19 BST, Mike Schinkel <m...@newclarity.net> wrote: >> BTW, why has nobody ever mentioned Zephir on this list (that I am aware of?) > > Zephir is an interesting idea that has never quite fulfilled its aims. The > Phalcon developers hoped that creating a more PHP-like language would allow > more people to work on extensions such as their framework, but it doesn't > seem to have worked out that way. > > The worse problem was that Zephir itself had very few contributors. A few > years ago, the project came close to shutting down as there was nobody left > to maintain it; Phalcon was to be rewritten in PHP. > <https://blog.phalcon.io/post/the-future-of-phalcon> Since then, somebody has > stepped up, but Phalcon work is still focussed on the PHP rewrite, with the > intention of a smaller, optional, extension providing performance-critical > components. <https://blog.phalcon.io/post/phalcon-roadmap> Thank you for the details about Zephir, as I was not fully aware of its history. On the surface it looks like a really promising project, it is a shame that more people are not interested in seeing it be successful so that it could be maintained and improved. BTW, my rhetorical comment asking why nobody mentions it on the list was really an indirect reference to the "Using and Mentioning Third-party Packages" thread[1] I have wanted to comment on but have not had the time to read the full thread and craft an argument that I hope would be compelling to many people. > Meanwhile, PHP 7 and 8 have massively increased both the performance and the > capability of code written in PHP, and even FFI to bridge to existing native > binaries (although I gather there's a lot that could be improved to make that > more useful). > <snip> > ...except to say that I think we should be aiming to reduce the difference > between what can be done in extensions and what in PHP code, rather than > planning any new such differences. True, but let us split this into two discussions. One discussion you made here which is "make PHP better rather than make ways to extend PHP externally." The 2nd is the discussion I was having which was more constrained, i.e. "In the case of operator overloading that I argue we should not offer in userland I was exploring the idea of adding internal features that allow extensions to be developed to address those use-cases, and especially for extensions that would be included in core, not necessarily for optional extensions." Before we address the broad question let us address the narrow one I was focused on. First, do you think we should add general operator overloading as in C++, Python, C#, Swift, Ruby, Kotlin and Dart, or do you agree that adding it would be opening Pandora's box? If you think we should add operator overloading then we can agree to disagree. If you agree we should not add then do you agree that we could add operator overloading for specific classes in core, such as if we added a Money or Currency class? Ignore whether you think we should add a Money or Currency class — assume we should — and just answer if you think we should allow operator overloading for classes added to core where we can standardize the operator's meanings across all uses of PHP? If you've gotten this far and we are still in agreement then I was looking for a way to make it easier to add operator overloading for classes to be added to core. So your comment "to reduce the difference between what can be done in extensions and what in PHP code, rather than planning any new such differences" was really presenting my argument as apples when I was instead discussing oranges. Though I can certainly understand if that was not previously clear to you, hopefully it is now. (Alternately, for operator overloading, do you see any way in which we could constrain userland operator overloads such that we would not end up many different competing meanings of plus, minus, times, divide, equals, not equals, etc. for similar types of classes? I certainly cannot envision how we could constrain it in a useful way.) ----------- With that covered I'll respond to your more general argument which I characterized as you advocating to "Make PHP better rather than make ways to extend PHP externally." Generally, I agree. Where it is possible — and not harmful — to do so, it would be better to make PHP better than to just find ways to extend PHP in other ways. But let us be realistic and honest with each other. PHP has many strengths but it also has weaknesses that it will never be able to address without changing the essential nature of PHP and without huge BC breakage. And for those things were PHP is not great — or where we see foot-guns so we explicitly do not want to add to userland — it would make sense to enable PHP to be extended through other means. And *especially* in ways that do not require being in control of the server PHP is running on given how ubiquitous managed hosting has become for many who run PHP apps. I discussed with you privately several years ago how I thought supporting WebAssembly[2][3] would be huge boon to PHP, and at the time I seem to remember you barely knew about it and were thus dismissive. IMO then and now, supporting WASM in PHP Core would make certain things possible that would only otherwise be possible in extensions written in C or I guess via the FFI in other languages, but make it possible without having control of the server PHP is running on, and in any language that supports WASM. What things is PHP not great at? Real-time code, not using lots of memory when processing huge data structures, C-levels of performance, and probably a few other things. The thing is, if we allow people to extend PHP in other ways and PHP is just as good as extending in those other ways, people will almost universally default to using PHP. So I don't see danger in harming PHP by enabling PHP to be extended in other languages for those things PHP is not good at. > The overall trend is to have only what's absolutely necessary in an extension. Not sure what you mean here. When I say "extension in core" I mean an extension that ships with core. If that is a trend to move away from for some reason then substitute "in core" for every place I wrote "an extension in core." Effectively that point is red herring for the point I was trying to make. > and there have even been suggestions that some built-in functions would be > better off implemented in PHP itself, if the right low-level features were > included. Now implementing PHP in PHP — assuming I understand what you mean — is something I have been wanting and occasionally mentioning for years. Specifically I think it would make great sense to have some of the standard library that ships in core to be written in PHP which would open up the ability for more people to contribute to PHP core taking some burden off the maintainers of core who program in C, and would mean that every improvement in the C part of PHP would make all the PHP parts of PHP better. Is that what you meant? If yes, want to collaborate on an RFC? I know at least a few others who would jump at the change to pursue this. -Mike [1] https://externals.io/message/125279 [2] https://en.wikipedia.org/wiki/WebAssembly [3] https://webassembly.org/
