Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125513
Feedback-ID: id5114917:Fastmail
Date: Wed, 11 Sep 2024 21:55:52 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Zephir, and other tangents
User-Agent: K-9 Mail for Android
In-Reply-To: <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net>
References: <A247BB36-9FD1-4AAF-AAB8-82DBD9DE3550@newclarity.net> <CA697780-BC2D-4054-A9FD-523E08236732@rwec.co.uk> <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net>
Message-ID: <D337D5FE-4F08-45FB-BF84-24F1AE5ECEA4@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 11 September 2024 20:12:53 BST, Mike Schinkel <mike@newclarity=2Enet> w=
rote:
>> It also risks conflicting with a future language feature that overlaps,=
 as happened with all native functions marked as accepting string automatic=
ally coercing nulls, but all userland ones rejecting it=2E Deprecating that=
 difference has caused a lot of friction=2E
>
>That is a little different in that it was a behavior that occurred in bot=
h core and userland whereas only allowing operator overloading in core woul=
d mean there would be not userland differences that could conflict=2E


Historically, that's what we had for scalar parameters=2E All the way back=
 in PHP 4 (I think), the engine had a function called "zend_parse_parameter=
s" (ZPP), which took the PHP values a user provided, and either converted t=
hem to the desired C type, or rejected them=2E In effect, it allowed functi=
ons defined in extensions to declare scalar typed parameters=2E

Then in PHP 7, we added scalar type declarations for parameters in userlan=
d functions, and had to work out how they fitted with those internal functi=
ons=2E Part of the motivation for the strict_types toggle was to manage the=
ir behaviour; and userland functions require explicit nullable types, where=
as ZPP historically coerced nulls regardless=2E

Anything we let extensions do could end up with the same dilemma later: do=
 we match userland to existing extension behaviour, change extension behavi=
our, or live with an awkward inconsistency?


>WebAssembly has a deny-by-default design so could be something to serious=
ly consider for extensibility in PHP=2E Implementations start with a full s=
andbox[2] and only add what they need to avoid those kinds of concerns=2E=
=20

The problem is that second part: in order to be useful for writing a PHP e=
xtension, what would we need to let through the sandbox?

For some simple extensions, the equivalent of FFI would be enough: call th=
is special function, and some code runs in the sandbox and spits out an ans=
wer=2E=20

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=2E Maybe it's possible, but how is not obvious to me=2E



>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 t=
ime if PHP itself improves there is reason to migrate more code to PHP=2E =
=20
>
>But there can still be reasons to not allow some thing in userland=2E Som=
e things like __toArray=2E

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 r=
educe the difficulty of building extensions=2E

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 t=
hings you currently need extensions to do=2E Things like efficient string b=
uffers and binary stream manipulation, or attributes and magic methods to o=
verride object behaviour=2E

 Regards,
Rowan Tommins
[IMSoP]