Re: Zephir, and other tangents

On 11 September 2024 03:57:23 BST, Mike Schinkel <mike@newclarity.net> wrote: >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. Perhaps you're unaware that classes in core already can, and do, provide operator overloading. GMP is the "poster child" for it, overloading a bunch of mathematical operators, but the mechanism it uses to do so is reasonably straightforward and available to any extension. I've never liked that approach, because it means users can't write polyfills, or even stub objects, that have these special behaviours. It feels weird for the language to define behaviour that isn't expressible in the language. It also risks conflicting with a future language feature that overlaps, as happened with all native functions marked as accepting string automatically coercing nulls, but all userland ones rejecting it. Deprecating that difference has caused a lot of friction. >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. This is the tricky part for me: some of the things people want to do in extensions are explicitly the kinds of thing a shared host would not want them to, such as interface to system libraries, perform manual memory management, interact with other processes on the host. >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. If WASM can provide some kind of sandbox, while still allowing a good portion of the features people actually want to write in extensions, I can imagine that being useful. But how exactly that would work I have no idea, so can't really comment further. >> The overall trend is to have only what's absolutely necessary in an extension. > >Not sure what you mean here. I mean, like Phalcon plans to, ship both a binary extension and a PHP library, putting only certain essential functionality in the extension. It's how MongoDB ships their PHP bindings, for instance - the extension provides low-level protocol support which is not intended for every day use; the library is then free to evolve the user-facing parts more freely. Regards, Rowan Tommins [IMSoP]