Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125623
Precedence: bulk
MIME-Version: 1.0
References: <CAMrTa2E2m00gOoGy5FbvkrLwM1AUP3ZmJXHkxh_R2qEszQ=NWA@mail.gmail.com>
 <2551c06a-ec1f-4870-a590-aeb5752fc944@rwec.co.uk> <CAMrTa2FLJwjwy9uGpRJJJFMUD1vs=vqzv8x2VxMsYeBqMN4m9Q@mail.gmail.com>
 <0f0444eb-8fc5-4c56-8528-5aa528988e73@rwec.co.uk> <e4c478c5-03b5-4cfd-95c4-6161d88557fa@app.fastmail.com>
 <12de3d03-3426-44f8-a83f-d686d2034912@rwec.co.uk> <3f6d4409-d370-4391-a8e5-a8a50d8da793@gmx.de>
 <b3746139-a4f1-4a98-a7f7-5d43bbe7b52a@app.fastmail.com>
In-Reply-To: <b3746139-a4f1-4a98-a7f7-5d43bbe7b52a@app.fastmail.com>
Date: Wed, 18 Sep 2024 18:46:51 +0300
Message-ID: <CAAwdEzAZZjv7Vj6TV-kVbpRKh31R+0u9VwtDJgfjnGgXfy8g=g@mail.gmail.com>
Subject: Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000000f55d1062266b884"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--0000000000000f55d1062266b884
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 18, 2024 at 6:11=E2=80=AFPM Rowan Tommins [IMSoP] <imsop.php@rw=
ec.co.uk>
wrote:

> On Wed, 18 Sep 2024, at 15:19, Christoph M. Becker wrote:
> >> Maybe it would be "useful enough" to just restrict to left-hand side:
> >
> > In my opinion, this is the only reasonable way to implement operator
> > overloads in PHP.  It is easy to understand, and what can easily be
> > understood is easy to explain, document, and to reason about.  I do not
> > understand why we're talking about commutative operations; even the
> > inconspicuous plus operator is not commutative in PHP
> > (https://3v4l.org/nQcL5).
>
> There are really three different things we shouldn't confuse:
>
> 1) Commutativity of the operation, as in $a + $b and $b + $a having the
> same result. As you say, this is a non-goal; we already have examples of
> non-commutative operators in PHP, and there are plenty more that have bee=
n
> given.
>
> 2) Commutativity of the *resolution*. This is slightly subtler: if $a and
> $b both have implementations of the operator, should $a + $b and $b + $a
> call the same implementation? We can say "no", but it may be surprising t=
o
> some users that if $b is a sub-class of $a, its version of + isn't used b=
y
> preference.
>
> 3) Resolution when *only one side has an implementation*. For instance,
> how do you define an overload for 1 / $object? Or for (new DateTime) + (n=
ew
> MySpecialDateOffset)? It's possible to work around this if the custom cla=
ss
> has to be on the left, but probably not very intuitive.
>
> It's also worth considering that the *resolution* of PHP's operators
> aren't currently determined by their left-hand side, e.g. int + float and
> float + int both return a float, which certainly feels like "preferring t=
he
> float implementation regardless of order", even if PHP doesn't technicall=
y
> implement it that way.
>
>
>
How about doing it like in Python, where there is `__add__` and `__radd__`?

And the engine could call $op1->add($op2) if $op1 is an object and `add()`
is implemented, or otherwise call $op2->rightAdd($op1) if $op2 is an object
and `rightAdd()` is implemented, or otherwise fail with an error.

We could have (distinct) interfaces for both `add()` and `rightAdd()`.
Or use magic methods like `__add()` and `__rightAdd()` to allow stricter
types instead of `mixed` on the other operand. I think there is no extra
complexity for the engine by using magic methods or interfaces.

--=20
Alex

--0000000000000f55d1062266b884
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 18, 2024 at 6:11=E2=80=AFPM R=
owan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.php@=
rwec.co.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">On Wed, 18 Sep 2024, at 15:19, Christoph M. Becker wrote:<br>
&gt;&gt; Maybe it would be &quot;useful enough&quot; to just restrict to le=
ft-hand side:<br>
&gt;<br>
&gt; In my opinion, this is the only reasonable way to implement operator<b=
r>
&gt; overloads in PHP.=C2=A0 It is easy to understand, and what can easily =
be<br>
&gt; understood is easy to explain, document, and to reason about.=C2=A0 I =
do not<br>
&gt; understand why we&#39;re talking about commutative operations; even th=
e<br>
&gt; inconspicuous plus operator is not commutative in PHP<br>
&gt; (<a href=3D"https://3v4l.org/nQcL5" rel=3D"noreferrer" target=3D"_blan=
k">https://3v4l.org/nQcL5</a>).<br>
<br>
There are really three different things we shouldn&#39;t confuse:<br>
<br>
1) Commutativity of the operation, as in $a + $b and $b + $a having the sam=
e result. As you say, this is a non-goal; we already have examples of non-c=
ommutative operators in PHP, and there are plenty more that have been given=
.<br>
<br>
2) Commutativity of the *resolution*. This is slightly subtler: if $a and $=
b both have implementations of the operator, should $a + $b and $b + $a cal=
l the same implementation? We can say &quot;no&quot;, but it may be surpris=
ing to some users that if $b is a sub-class of $a, its version of + isn&#39=
;t used by preference.<br>
<br>
3) Resolution when *only one side has an implementation*. For instance, how=
 do you define an overload for 1 / $object? Or for (new DateTime) + (new My=
SpecialDateOffset)? It&#39;s possible to work around this if the custom cla=
ss has to be on the left, but probably not very intuitive.<br>
<br>
It&#39;s also worth considering that the *resolution* of PHP&#39;s operator=
s aren&#39;t currently determined by their left-hand side, e.g. int + float=
 and float + int both return a float, which certainly feels like &quot;pref=
erring the float implementation regardless of order&quot;, even if PHP does=
n&#39;t technically implement it that way.<br>
<br><br></blockquote><div><br></div><div>How about doing it like in Python,=
 where there is `__add__` and `__radd__`?</div><div><br></div><div>And the =
engine could call $op1-&gt;add($op2) if $op1 is an object and `add()` is im=
plemented, or otherwise call $op2-&gt;rightAdd($op1) if $op2 is an object a=
nd `rightAdd()` is implemented, or otherwise fail with an error.</div><div>=
<br></div><div>We could have (distinct) interfaces for both `add()` and `ri=
ghtAdd()`.</div><div>Or use magic methods like `__add()` and `__rightAdd()`=
 to allow stricter types instead of `mixed` on the other operand. I think t=
here is no extra complexity for the engine by using magic methods or interf=
aces.</div><div><br></div><div>--=C2=A0</div><div>Alex</div></div></div>

--0000000000000f55d1062266b884--