On 11 September 2024 03:57:23 BST, Mike Schinkel <m...@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]
