Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125575
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 16 Sep 2024 23:36:25 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <e229771e-c23f-4faa-a126-755017d77575@app.fastmail.com>
In-Reply-To: 
 <CAMrTa2FwzgJpqGi_LB9bHv4u2JXBTLJK0xry4aLAP0KbJ8s03Q@mail.gmail.com>
References: 
 <CAMrTa2E2m00gOoGy5FbvkrLwM1AUP3ZmJXHkxh_R2qEszQ=NWA@mail.gmail.com>
 <ca0336fc-a6ed-4ced-a3e4-2322bfa6dc76@app.fastmail.com>
 <CAMrTa2FwzgJpqGi_LB9bHv4u2JXBTLJK0xry4aLAP0KbJ8s03Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Sep 16, 2024, at 2:47 AM, Jordan LeDoux wrote:
> On Sun, Sep 15, 2024 at 9:12=E2=80=AFPM Larry Garfield <larry@garfield=
tech.com> wrote:
>>=20
>> 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.
>>=20
>
> I will perhaps respond with more detail to the rest of your message=20
> later, but I wanted to address this specifically, because I also feel=20
> that the original RFC I wrote didn't explain that well. The situation=20
> this bit was referring to is as follows:
>
> You have an object Foo that implements an overload for the `<=3D>`=20
> operator. The proposed signature for `<=3D>` was simply:=20
>
> `operator <=3D>($other): int`
>
> This operator did not have an `OperandPosition` argument. The reason=20
> for this was to prevent developers from creating situations where `5 >=20
> $foo` is true and `5 < $foo` is true. Instead, internally it did the=20
> same sort of reordering that the engine currently does. It calls the=20
> implementation the developer defined, and then checks if the object=20
> that the implementation was called from was on the right side of the=20
> operator. If it was, then it multiplies the result of the user defined=20
> overload by -1. Multiplying the result of the overload ONLY when the=20
> overload is called for the right side is equivalent to flipping the=20
> order. So `5 > $foo` is multiplied by -1 and then evaluated as if it=20
> were `$foo < 5`. This is an edge case, but it was an important one in=20
> my mind.
>
> It would be entirely unnecessary if we allowed the `<=3D>` overload to=20
> know what position it was in, but that would enable lots of developer=20
> mistakes in my mind for no real gain. Instead, developers should just=20
> implement the overload as if the object assumes it will always be=20
> called from the left side of the comparison.
>
> Jordan

OK, that makes a lot more sense.  Reading through the text of the RFC, I=
 didn't catch that it only multiplied by -1 if the comparing object was =
on the right.  The implementation is fine, but if you do for a second ro=
und, making that a bit clearer would be helpful.

--Larry Garfield