On 11 September 2024 03:57:23 BST, Mike Schinkel <[email protected]> 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]