Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125561
Precedence: bulk
MIME-Version: 1.0
References: <CAMrTa2E2m00gOoGy5FbvkrLwM1AUP3ZmJXHkxh_R2qEszQ=NWA@mail.gmail.com>
 <ca0336fc-a6ed-4ced-a3e4-2322bfa6dc76@app.fastmail.com>
In-Reply-To: <ca0336fc-a6ed-4ced-a3e4-2322bfa6dc76@app.fastmail.com>
Date: Mon, 16 Sep 2024 00:47:58 -0700
Message-ID: <CAMrTa2FwzgJpqGi_LB9bHv4u2JXBTLJK0xry4aLAP0KbJ8s03Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000072723b062237cbd8"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000072723b062237cbd8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 15, 2024 at 9:12=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

>
> The "multiply by -1 for <=3D>" bit I don't fully understand the point of.
> The RFC tries to explain, but I don't quite grok it.
>
>
I will perhaps respond with more detail to the rest of your message later,
but I wanted to address this specifically, because I also feel that the
original RFC I wrote didn't explain that well. The situation this bit was
referring to is as follows:

You have an object Foo that implements an overload for the `<=3D>` operator=
.
The proposed signature for `<=3D>` was simply:

`operator <=3D>($other): int`

This operator did not have an `OperandPosition` argument. The reason for
this was to prevent developers from creating situations where `5 > $foo` is
true and `5 < $foo` is true. Instead, internally it did the same sort of
reordering that the engine currently does. It calls the implementation the
developer defined, and then checks if the object that the implementation
was called from was on the right side of the operator. If it was, then it
multiplies the result of the user defined overload by -1. Multiplying the
result of the overload ONLY when the overload is called for the right side
is equivalent to flipping the order. So `5 > $foo` is multiplied by -1 and
then evaluated as if it were `$foo < 5`. This is an edge case, but it was
an important one in my mind.

It would be entirely unnecessary if we allowed the `<=3D>` overload to know
what position it was in, but that would enable lots of developer mistakes
in my mind for no real gain. Instead, developers should just implement the
overload as if the object assumes it will always be called from the left
side of the comparison.

Jordan

--00000000000072723b062237cbd8
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 Sun, Sep 15, 2024 at 9:12=E2=80=AF=
PM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfi=
eldtech.com</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"><br>
The &quot;multiply by -1 for &lt;=3D&gt;&quot; bit I don&#39;t fully unders=
tand the point of.=C2=A0 The RFC tries to explain, but I don&#39;t quite gr=
ok it.<br>
<br></blockquote><div><br></div><div>I will perhaps respond with more detai=
l to the rest of your message later, but I wanted to address this specifica=
lly, because I also feel that the original RFC I wrote didn&#39;t explain t=
hat well. The situation this bit was referring to is as follows:<br><br></d=
iv><div>You have an object Foo that implements an overload for the `&lt;=3D=
&gt;` operator. The proposed signature for `&lt;=3D&gt;` was simply: <br><b=
r></div><div>`operator &lt;=3D&gt;($other): int`</div><div><br></div><div>T=
his operator did not have an `OperandPosition` argument. The reason for thi=
s was to prevent developers from creating situations where `5 &gt; $foo` is=
 true and `5 &lt; $foo` is true. Instead, internally it did the same sort o=
f reordering that the engine currently does. It calls the implementation th=
e developer defined, and then checks if the object that the implementation =
was called from was on the right side of the operator. If it was, then it m=
ultiplies the result of the user defined overload by -1. Multiplying the re=
sult of the overload ONLY when the overload is called for the right side is=
 equivalent to flipping the order. So `5 &gt; $foo` is multiplied by -1 and=
 then evaluated as if it were `$foo &lt; 5`. This is an edge case, but it w=
as an important one in my mind.</div><div><br></div><div>It would be entire=
ly unnecessary if we allowed the `&lt;=3D&gt;` overload to know what positi=
on it was in, but that would enable lots of developer mistakes in my mind f=
or no real gain. Instead, developers should just implement the overload as =
if the object assumes it will always be called from the left side of the co=
mparison.</div><div><br></div><div>Jordan<br></div></div></div>

--00000000000072723b062237cbd8--