On 11 September 2024 20:12:53 BST, Mike Schinkel <[email protected]> wrote:
>> 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.
>
>That is a little different in that it was a behavior that occurred in both core and userland
>whereas only allowing operator overloading in core would mean there would be not userland
>differences that could conflict.
Historically, that's what we had for scalar parameters. All the way back in PHP 4 (I think),
the engine had a function called "zend_parse_parameters" (ZPP), which took the PHP values
a user provided, and either converted them to the desired C type, or rejected them. In effect, it
allowed functions defined in extensions to declare scalar typed parameters.
Then in PHP 7, we added scalar type declarations for parameters in userland functions, and had to
work out how they fitted with those internal functions. Part of the motivation for the strict_types
toggle was to manage their behaviour; and userland functions require explicit nullable types,
whereas ZPP historically coerced nulls regardless.
Anything we let extensions do could end up with the same dilemma later: do we match userland to
existing extension behaviour, change extension behaviour, or live with an awkward inconsistency?
>WebAssembly has a deny-by-default design so could be something to seriously consider for
>extensibility in PHP. Implementations start with a full sandbox[2] and only add what they need to
>avoid those kinds of concerns.
The problem is that second part: in order to be useful for writing a PHP extension, what would we
need to let through the sandbox?
For some simple extensions, the equivalent of FFI would be enough: call this special function, and
some code runs in the sandbox and spits out an answer.
For others, you need something that's easier to trust than a native binary, but also integrates
tightly into the language to do things PHP code can't do. Maybe it's possible, but how is
not obvious to me.
>I think that actually supports what I was saying; people would gravitate to only doing in an
>extension what they cannot do in PHP itself, and over time if PHP itself improves there is reason to
>migrate more code to PHP.
>
>But there can still be reasons to not allow some thing in userland. Some things like __toArray.
I think there's ideas pulling in opposite directions here: on the one hand, using the
difficulty of building extensions as a deliberate "speed bump" to avoid people using
features "badly"; but on the other hand, wanting to reduce the difficulty of building
extensions.
I think the latter is a more noble goal, and one way to help is to make it less *necessary* to build
extensions, by adding to the core language the things you currently need extensions to do. Things
like efficient string buffers and binary stream manipulation, or attributes and magic methods to
override object behaviour.
Regards,
Rowan Tommins
[IMSoP]