Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125512
Precedence: bulk
MIME-Version: 1.0
References: <A247BB36-9FD1-4AAF-AAB8-82DBD9DE3550@newclarity.net>
 <CA697780-BC2D-4054-A9FD-523E08236732@rwec.co.uk> <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net>
In-Reply-To: <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net>
Date: Wed, 11 Sep 2024 14:43:01 -0600
Message-ID: <CA+Jpajkx0OraH7GQyB5gECtPOo2JP=RzuSwqfv4AZGY+a+ryPw@mail.gmail.com>
Subject: Re: [PHP-DEV] Zephir, and other tangents
To: Mike Schinkel <mike@newclarity.net>
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000dc4fb40621de09cd"
From: hamiegold@gmail.com (Hammed Ajao)

--000000000000dc4fb40621de09cd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 11, 2024 at 1:13=E2=80=AFPM Mike Schinkel <mike@newclarity.net>=
 wrote:

> Hi Rowan,
>
> > On Sep 11, 2024, at 2:55 AM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.u=
k>
> wrote:
> > Perhaps you're unaware that classes in core already can, and do, provid=
e
> operator overloading. GMP is the "poster child" for it, overloading a bun=
ch
> of mathematical operators, but the mechanism it uses to do so is reasonab=
ly
> straightforward and available to any extension.
>
> I was making an (evidently) uninformed assuming that it was non-trivial t=
o
> add operator overloading at the C level. If it is easy, then my comments
> were moot.
>
> 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 i=
n
> the language.
>
> 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.
>
> 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 develop=
er
> who implements them (that would be the same kind of developer who names
> their variables after Game of Thrones characters.)
>
> 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 operator=
s
> because it has such smaller scope and is actually quote useful for a comm=
on
> 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 bot=
h
> core and userland whereas only allowing operator overloading in core woul=
d
> 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.
> >
> > 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 ca=
n
> 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.
>
> Also, all memory manipulations sandboxed, though there are still potentia=
l
> 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 woul=
d
> 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 f=
or
> reference: [4][5][6]
>
>
> >>> The overall trend is to have only what's absolutely necessary in an
> extension.
> >>
> >> Not sure what you mean here.
> >
> > 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.
>
> 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.
>
> -Mike
>
> [1] https://www.mail-archive.com/internals@lists.php.net/msg100001.html
> [2]
> https://thenewstack.io/how-webassembly-offers-secure-development-through-=
sandboxing/
> [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/



Using WebAssembly (Wasm) for PHP doesn't make much sense. PHP already runs
on its own virtual machine server-side, so adding another VM (Wasm) would
just introduce unnecessary complexity and overhead. Additionally, would
this be the LLVM or Cranelift variant of Wasm?

For extensions, Wasm would perform even worse than current implementations,
no matter how it's integrated. Presently, I define zif_handler function
pointers that operate on the current execution frame and return value,
triggered when the engine detects an internal function (fbc). This approach
is as direct as it gets.

Suggesting AssemblyScript, especially in this context, seems illogical.
Have you actually worked with WebAssembly and considered performance
implications, or is this based on theoretical knowledge?

Your point about operator overloading doesn't seem valid either. Consider
the following:

```php
class X {
    public function plus(X $that) {}
    public function equals(X $that) {}
}
```

In this case, `plus` could represent any behavior, as could `equals`. If I
wanted to, I could implement `plus` to perform what `equals` does and vice
versa. Should we consider methods broken just because their names can be
arbitrary?

PHP already distinguishes between comparison operators for objects:

```php
<?php
$obj1 =3D $obj2 =3D new stdclass;
assert($obj1 =3D=3D=3D $obj2); // compares object IDs
assert($obj1 =3D=3D $obj2);  // compares properties
$obj1 =3D new stdclass;
assert($obj1 !=3D=3D $obj2);
assert($obj1 =3D=3D $obj2);
```

`=3D=3D=3D` compares object IDs, while `=3D=3D` compares their properties. =
Beyond
this, there's little reason to apply an operator to an object directly. Why
would you need to call `$user1 + $user2` or similar operations on an
object? What scenario would break by allowing operator overloads?

However, consider a case where comparing just one property of an object
(like a hash) is enough to determine equality. Wouldn't it be great if,
without changing any of the calling code, the engine compared `$this->hash
=3D=3D=3D $that->hash` when `$this =3D=3D $that` is invoked, instead of all
properties? Without operator overloading, I'd have to define an `equals`
method and replace every `$obj =3D=3D $x` call with `$obj->equals($x)`.

Moreover, operator overloading unlocks new possibilities for algorithm
design. For example, you could define complex mathematical operations on
custom objects, enabling you to express algorithms more concisely and
naturally. Imagine implementing vector addition, matrix multiplication, or
symbolic computation directly in PHP. Instead of verbose method calls like
`$vec1->add($vec2)` or `$matrix1->multiply($matrix2)`, you could use simple
and intuitive syntax like `$vec1 + $vec2` or `$matrix1 * $matrix2`. This is
particularly useful for domain-specific algorithms where overloading
enhances readability and performance.

Operator overloading isn't just about convenience. It opens the door to
more expressive algorithms, better readability, and reduces boilerplate
code, all while maintaining backward compatibility with existing PHP
behavior.

Cheers,
Hammed.

--000000000000dc4fb40621de09cd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 11, 2024 at 1:13=E2=80=AF=
PM Mike Schinkel &lt;<a href=3D"mailto:mike@newclarity.net">mike@newclarity=
.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">Hi Rowan,<br>
<br>
&gt; On Sep 11, 2024, at 2:55 AM, Rowan Tommins [IMSoP] &lt;<a href=3D"mail=
to:imsop.php@rwec.co.uk" target=3D"_blank">imsop.php@rwec.co.uk</a>&gt; wro=
te:<br>
&gt; Perhaps you&#39;re unaware that classes in core already can, and do, p=
rovide operator overloading. GMP is the &quot;poster child&quot; for it, ov=
erloading a bunch of mathematical operators, but the mechanism it uses to d=
o so is reasonably straightforward and available to any extension.<br>
<br>
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 we=
re moot.=C2=A0 <br>
<br>
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<br>
<br>
&gt; I&#39;ve never liked that approach, because it means users can&#39;t w=
rite polyfills, or even stub objects, that have these special behaviours. I=
t feels weird for the language to define behaviour that isn&#39;t expressib=
le in the language. <br>
<br>
Understood. In _general_ I don&#39;t like it either, but I will use as an a=
nalogy a prior discussion regarding __toArray, and I quote[1]:<br>
<br>
&quot;For the &quot;convertible to array&quot; case, I think __toArray, or =
an interface specifying just that one method, would make more sense than co=
mbining it with the existing interfaces. I&#39;m sceptical of that concept,=
 though, because most objects could be converted to many different arrays i=
n different circumstances, each of which should be given a different and de=
scriptive name.&quot;<br>
<br>
I am of course quoting you.=C2=A0 =C2=A0<br>
<br>
Similarly, operators could mean different things, e.g. it is possible to ha=
ve different meaning of equal, and even different meanings of plus. Or wors=
e 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.)=C2=A0 <br>
<br>
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.=
<br>
<br>
&gt; It also risks conflicting with a future language feature that overlaps=
, as happened with all native functions marked as accepting string automati=
cally coercing nulls, but all userland ones rejecting it. Deprecating that =
difference has caused a lot of friction.<br>
<br>
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.<br>
<br>
Whatever the case, if there are only two options: 1.) no operator overloadi=
ng, and 2.) userland operator overloading I would far prefer the former.<br=
>
<br>
&gt; This is the tricky part for me: some of the things people want to do i=
n extensions are explicitly the kinds of thing a shared host would not want=
 them to, such as interface to system libraries, perform manual memory mana=
gement, interact with other processes on the host.<br>
&gt; <br>
&gt; 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&#39;t really comment further.<br>
<br>
WebAssembly has a deny-by-default design so could be something to seriously=
 consider for extensibility in PHP. Implementations start with a full sandb=
ox[2] and only add what they need to avoid those kinds of concerns. <br>
<br>
Also, all memory manipulations sandboxed, though there are still potential =
vulnerabilities within the sandbox so the project that incorporates WASM ne=
eds to be careful.=C2=A0 WASM written in C/C++ can have memory issues just =
like in regular C/C++, for example.=C2=A0 One option would be to allow only=
 AssemblyScript source for WASM. Another would be a config option that a we=
b-host could set to only allow signed modules, but that admittedly would op=
en another can of worms.=C2=A0 But the memory issues cannot leak out of the=
 module or affect other modules nor the system, if implemented with total m=
emory constraints.<br>
<br>
That said, web hosts can&#39;t stop PHP developers from creating infinite l=
oops so the memory issues with WASM don&#39;t feel like too much bigger of =
a concern given their sandboxed nature.=C2=A0 I&#39;ve copied numerous othe=
r links for reference: [4][5][6]<br>
<br>
<br>
&gt;&gt;&gt; The overall trend is to have only what&#39;s absolutely necess=
ary in an extension.<br>
&gt;&gt; <br>
&gt;&gt; Not sure what you mean here.<br>
&gt; <br>
&gt; I mean, like Phalcon plans to, ship both a binary extension and a PHP =
library, putting only certain essential functionality in the extension. It&=
#39;s how MongoDB ships their PHP bindings, for instance - the extension pr=
ovides 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.<br>
<br>
Gotcha.=C2=A0 <br>
<br>
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 tim=
e if PHP itself improves there is reason to migrate more code to PHP.=C2=A0=
 <br>
<br>
But there can still be reasons to not allow some thing in userland. Some th=
ings like __toArray.<br>
<br>
-Mike<br>
<br>
[1] <a href=3D"https://www.mail-archive.com/internals@lists.php.net/msg1000=
01.html" rel=3D"noreferrer" target=3D"_blank">https://www.mail-archive.com/=
internals@lists.php.net/msg100001.html</a><br>
[2] <a href=3D"https://thenewstack.io/how-webassembly-offers-secure-develop=
ment-through-sandboxing/" rel=3D"noreferrer" target=3D"_blank">https://then=
ewstack.io/how-webassembly-offers-secure-development-through-sandboxing/</a=
><br>
[3] <a href=3D"https://radu-matei.com/blog/practical-guide-to-wasm-memory/"=
 rel=3D"noreferrer" target=3D"_blank">https://radu-matei.com/blog/practical=
-guide-to-wasm-memory/</a><br>
[4] <a href=3D"https://www.cs.cmu.edu/~csd-phd-blog/2023/provably-safe-sand=
boxing-wasm/" rel=3D"noreferrer" target=3D"_blank">https://www.cs.cmu.edu/~=
csd-phd-blog/2023/provably-safe-sandboxing-wasm/</a><br>
[5] <a href=3D"https://chatgpt.com/share/b890aede-1c82-412a-89a9-deae99da50=
6e" rel=3D"noreferrer" target=3D"_blank">https://chatgpt.com/share/b890aede=
-1c82-412a-89a9-deae99da506e</a><br>
[6] <a href=3D"https://www.assemblyscript.org/" rel=3D"noreferrer" target=
=3D"_blank">https://www.assemblyscript.org/</a></blockquote><div><br></div>=
<div><br></div><div>Using WebAssembly (Wasm) for PHP doesn&#39;t make much =
sense. PHP already runs on its own virtual machine server-side, so adding a=
nother VM (Wasm) would just introduce unnecessary complexity and overhead. =
Additionally, would this be the LLVM or Cranelift variant of Wasm?<br><br>F=
or extensions, Wasm would perform even worse than current implementations, =
no matter how it&#39;s integrated. Presently, I define zif_handler function=
 pointers that operate on the current execution frame and return value, tri=
ggered when the engine detects an internal function (fbc). This approach is=
 as direct as it gets.<br><br>Suggesting AssemblyScript, especially in this=
 context, seems illogical. Have you actually worked with WebAssembly and co=
nsidered performance implications, or is this based on theoretical knowledg=
e?<br></div><div><br></div><div>Your point about operator overloading doesn=
&#39;t seem valid either. Consider the following:<br><br>```php<br>class X =
{<br>=C2=A0 =C2=A0 public function plus(X $that) {}<br>=C2=A0 =C2=A0 public=
 function equals(X $that) {}<br>}<br>```<br><br>In this case, `plus` could =
represent any behavior, as could `equals`. If I wanted to, I could implemen=
t `plus` to perform what `equals` does and vice versa. Should we consider m=
ethods broken just because their names can be arbitrary?<br><br>PHP already=
 distinguishes between comparison operators for objects:<br><br>```php<br>&=
lt;?php<br>$obj1 =3D $obj2 =3D new stdclass;<br>assert($obj1 =3D=3D=3D $obj=
2); // compares object IDs<br>assert($obj1 =3D=3D $obj2); =C2=A0// compares=
 properties<br>$obj1 =3D new stdclass;<br>assert($obj1 !=3D=3D $obj2);<br>a=
ssert($obj1 =3D=3D $obj2);<br>```<br><br>`=3D=3D=3D` compares object IDs, w=
hile `=3D=3D` compares their properties. Beyond this, there&#39;s little re=
ason to apply an operator to an object directly. Why would you need to call=
 `$user1 + $user2` or similar operations on an object? What scenario would =
break by allowing operator overloads?<br><br>However, consider a case where=
 comparing just one property of an object (like a hash) is enough to determ=
ine equality. Wouldn&#39;t it be great if, without changing any of the call=
ing code, the engine compared `$this-&gt;hash =3D=3D=3D $that-&gt;hash` whe=
n `$this =3D=3D $that` is invoked, instead of all properties? Without opera=
tor overloading, I&#39;d have to define an `equals` method and replace ever=
y `$obj =3D=3D $x` call with `$obj-&gt;equals($x)`.<br><br>Moreover, operat=
or overloading unlocks new possibilities for algorithm design. For example,=
 you could define complex mathematical operations on custom objects, enabli=
ng you to express algorithms more concisely and naturally. Imagine implemen=
ting vector addition, matrix multiplication, or symbolic computation direct=
ly in PHP. Instead of verbose method calls like `$vec1-&gt;add($vec2)` or `=
$matrix1-&gt;multiply($matrix2)`, you could use simple and intuitive syntax=
 like `$vec1 + $vec2` or `$matrix1 * $matrix2`. This is particularly useful=
 for domain-specific algorithms where overloading enhances readability and =
performance.<br><br>Operator overloading isn&#39;t just about convenience. =
It opens the door to more expressive algorithms, better readability, and re=
duces boilerplate code, all while maintaining backward compatibility with e=
xisting PHP behavior.<br></div><div><br></div><div>Cheers,</div><div>Hammed=
.</div></div></div>

--000000000000dc4fb40621de09cd--