Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125511
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
Subject: Re: [PHP-DEV] Zephir, and other tangents
In-Reply-To: <CA697780-BC2D-4054-A9FD-523E08236732@rwec.co.uk>
Date: Wed, 11 Sep 2024 15:12:53 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net>
References: <A247BB36-9FD1-4AAF-AAB8-82DBD9DE3550@newclarity.net>
 <CA697780-BC2D-4054-A9FD-523E08236732@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: mike@newclarity.net (Mike Schinkel)

Hi Rowan,

> On Sep 11, 2024, at 2:55 AM, Rowan Tommins [IMSoP] =
<imsop.php@rwec.co.uk> wrote:
> 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 was making an (evidently) uninformed assuming that it was non-trivial =
to add operator overloading at the C level. If it is easy, then my =
comments were moot. =20

That said, writing extensions in C and deploying them is non-trivial =
=E2=80=94comparing to writing code in PHP=E2=80=94 so there is that. =
=C2=AF\_(=E3=83=84)_/=C2=AF

> 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.=20

Understood. In _general_ I don't like it either, but I will use as an =
analogy a prior discussion regarding __toArray, and I quote[1]:

"For the "convertible to array" case, I think __toArray, or an interface =
specifying just that one method, would make more sense than combining it =
with the existing interfaces. I'm sceptical of that concept, though, =
because most objects could be converted to many different arrays in =
different circumstances, each of which should be given a different and =
descriptive name."

I am of course quoting you.  =20

Similarly, operators could mean different things, e.g. it is possible to =
have different meaning of equal, and even different meanings of plus. Or =
worse be applied in ways that are non-sensical to anybody but the =
developer who implements them (that would be the same kind of developer =
who names their variables after Game of Thrones characters.) =20

That is why I am not a fan of operator overloading, just as you were not =
a fan of __toArray which to me is less problematic than overloaded =
operators because it has such smaller scope and is actually quote useful =
for a common set of use-cases regardless of the potential for confusion. =
But I digress.

> 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.

Whatever the case, if there are only two options: 1.) no operator =
overloading, and 2.) userland operator overloading I would far prefer =
the former.

> 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.
>=20
> 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.

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.=20

Also, all memory manipulations sandboxed, though there are still =
potential vulnerabilities within the sandbox so the project that =
incorporates WASM needs to be careful.  WASM written in C/C++ can have =
memory issues just like in regular C/C++, for example.  One option would =
be to allow only AssemblyScript source for WASM. Another would be a =
config option that a web-host could set to only allow signed modules, =
but that admittedly would open another can of worms.  But the memory =
issues cannot leak out of the module or affect other modules nor the =
system, if implemented with total memory constraints.

That said, web hosts can't stop PHP developers from creating infinite =
loops so the memory issues with WASM don't feel like too much bigger of =
a concern given their sandboxed nature.  I've copied numerous other =
links for reference: [4][5][6]


>>> The overall trend is to have only what's absolutely necessary in an =
extension.
>>=20
>> Not sure what you mean here.
>=20
> 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.

Gotcha. =20

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. =20

But there can still be reasons to not allow some thing in userland. Some =
things like __toArray.

-Mike

[1] https://www.mail-archive.com/internals@lists.php.net/msg100001.html
[2] =
https://thenewstack.io/how-webassembly-offers-secure-development-through-s=
andboxing/
[3] https://radu-matei.com/blog/practical-guide-to-wasm-memory/
[4] =
https://www.cs.cmu.edu/~csd-phd-blog/2023/provably-safe-sandboxing-wasm/
[5] https://chatgpt.com/share/b890aede-1c82-412a-89a9-deae99da506e
[6] https://www.assemblyscript.org/