Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125501
Feedback-ID: id5114917:Fastmail
Date: Wed, 11 Sep 2024 07:55:41 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Zephir, and other tangents
User-Agent: K-9 Mail for Android
In-Reply-To: <A247BB36-9FD1-4AAF-AAB8-82DBD9DE3550@newclarity.net>
References: <A247BB36-9FD1-4AAF-AAB8-82DBD9DE3550@newclarity.net>
Message-ID: <CA697780-BC2D-4054-A9FD-523E08236732@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 03:57:23 BST, Mike Schinkel <mike@newclarity=2Enet> w=
rote:
>If you've gotten this far and we are still in agreement then I was lookin=
g for a way to make it easier to add operator overloading for classes to be=
 added to core=2E So your comment "to reduce the difference between what ca=
n 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 in=
stead discussing oranges=2E Though I can certainly understand if that was n=
ot previously clear to you, hopefully it is now=2E

Perhaps you're unaware that classes in core already can, and do, provide o=
perator overloading=2E GMP is the "poster child" for it, overloading a bunc=
h of mathematical operators, but the mechanism it uses to do so is reasonab=
ly straightforward and available to any extension=2E

I've never liked that approach, because it means users can't write polyfil=
ls, or even stub objects, that have these special behaviours=2E It feels we=
ird for the language to define behaviour that isn't expressible in the lang=
uage=2E=20

It also risks conflicting with a future language feature that overlaps, as=
 happened with all native functions marked as accepting string automaticall=
y coercing nulls, but all userland ones rejecting it=2E Deprecating that di=
fference has caused a lot of friction=2E


>And for those things were PHP is not great =E2=80=94 or where we see foot=
-guns so we explicitly do not want to add to userland =E2=80=94 it would ma=
ke sense to enable PHP to be extended through other means=2E  And *especial=
ly* in ways that do not require being in control of the server PHP is runni=
ng on given how ubiquitous managed hosting has become for many who run PHP =
apps=2E

This is the tricky part for me: some of the things people want to do in ex=
tensions are explicitly the kinds of thing a shared host would not want the=
m to, such as interface to system libraries, perform manual memory manageme=
nt, interact with other processes on the host=2E


>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 rem=
ember you barely knew about it and were thus dismissive=2E

If WASM can provide some kind of sandbox, while still allowing a good port=
ion of the features people actually want to write in extensions, I can imag=
ine that being useful=2E But how exactly that would work I have no idea, so=
 can't really comment further=2E


>> The overall trend is to have only what's absolutely necessary in an ext=
ension=2E
>
>Not sure what you mean here=2E

I mean, like Phalcon plans to, ship both a binary extension and a PHP libr=
ary, putting only certain essential functionality in the extension=2E 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 li=
brary is then free to evolve the user-facing parts more freely=2E

Regards,
Rowan Tommins
[IMSoP]