On 11 September 2024 20:12:53 BST, Mike Schinkel <m...@newclarity.net> 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]
