Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123993
Precedence: bulk
MIME-Version: 1.0
References: <b0e1725c-8abb-4b66-a810-ebe7b89d674e@app.fastmail.com>
In-Reply-To: <b0e1725c-8abb-4b66-a810-ebe7b89d674e@app.fastmail.com>
Date: Fri, 28 Jun 2024 11:39:30 -0700
Message-ID: <CAMrTa2EPFoV=jA8s7X_mRDWovkbHaB+bNzd5eyp490p4tA7xfA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000001ed346061bf79290"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000001ed346061bf79290
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 28, 2024 at 10:47=E2=80=AFAM Rob Landers <rob@bottled.codes> wr=
ote:

> Hello internals,
>
> I'd like to introduce a new RFC:
> https://wiki.php.net/rfc/operator_overrides_lite which extends the GMP
> extension to support a limited set of operator overriding to developers.
> It's designed to be limited and relatively simple, while still being quit=
e
> powerful. It would only be available if you have the GMP extension
> installed and enabled, but would allow for creating powerful unit librari=
es
> (such as representing money, duration, etc).
>
> I'm very interested in your feedback!
>
> This was initiated from a discussion in another thread:
> https://externals.io/message/123872
>
> Thanks for your time,
>
> Rob Landers
>

You probably have not actually looked at implementing this yet, so let me
give you some advice:

1. You probably are not yet aware that operands get reordered, or their
ordering is not guaranteed, when a comparison occurs. This is because there
is no op code (currently) for Greater Than or Greater Than Or Equal.
Instead the comparison is reordered so that the operands are swapped and a
Less Than or a Less Than Or Equal is performed. This is perfectly
acceptable until you need to determine whether the left or right operand's
function needs to be called, such as with objects.
2. The fact that the signature uses `mixed` for the typing removes a lot of
the safety features the previous RFC had, and makes a lot of the concerns
that stopped that RFC worse. In PHP currently, an object used with any
non-comparison operand results in a TypeError. In the previous proposal,
this behavior was preserved *even for objects which implement overloads*
unless they specifically listed the type as accepted in the overload
definition. What this did is ensure that anything OTHER than a TypeError
guaranteed the developer that they were dealing with an operator overload
that they could go inspect.
3. The private/protected distinction is fairly meaningless for the
functions that implement overloads, because the privacy of the function is
ignored completely when it is executed to evaluate an operator.
4. The `static` distinction is also fairly meaningless, as in PHP there is
no situation possible where an operator overload can occur WITHOUT it
operating on objects themselves.
5. Your voting choices actually constitute something that is not allowed
for RFCs. A 'yes' vote allows operator overloads for GMP, a 'no' vote
changes GMP to `final`. There is no option here to leave PHP as it
currently is, which is what a 'no' vote should mean.
6. The `comparable` function you propose doesn't actually have an operator
it corresponds to. There is no operator in PHP for "is the left value
comparable with the right value". There are operators for comparisons
themselves, which I assume you meant, but a bool is insufficient as a
return type for that.

There's probably more, but this is a start for you to make some
improvements and changes. However, I had to warn you before you put in too
much effort that I am fairly certain this RFC has very nearly zero chance
of passing.

Jordan

--0000000000001ed346061bf79290
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 Fri, Jun 28, 2024 at 10:47=E2=80=
=AFAM Rob Landers &lt;rob@bottled.codes&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div class=3D"msg8986034494577068337"><u=
></u><div><div>Hello internals,<br></div><div><br></div><div>I&#39;d like t=
o introduce a new RFC:=C2=A0<a href=3D"https://wiki.php.net/rfc/operator_ov=
errides_lite" rel=3D"noopener noreferrer" target=3D"_blank">https://wiki.ph=
p.net/rfc/operator_overrides_lite</a>=C2=A0which extends the GMP extension =
to support a limited set of operator overriding to developers. It&#39;s des=
igned to be limited and relatively simple, while still being quite powerful=
. It would only be available if you have the GMP extension installed and en=
abled, but would allow for creating powerful unit libraries (such as repres=
enting money, duration, etc).<br></div><div><br></div><div>I&#39;m very int=
erested in your feedback!<br></div><div><br></div><div>This was initiated f=
rom a discussion in another thread:=C2=A0<a href=3D"https://externals.io/me=
ssage/123872" rel=3D"noopener noreferrer" target=3D"_blank">https://externa=
ls.io/message/123872</a><br></div><div><br></div><div>Thanks for your time,=
<br></div><div><br></div><div>Rob Landers<br></div></div></div></blockquote=
><div><br></div><div>You probably have not actually looked at implementing =
this yet, so let me give you some advice:</div><div><br></div><div>1. You p=
robably are not yet aware that operands get reordered, or their ordering is=
 not guaranteed, when a comparison occurs. This is because there is no op c=
ode (currently) for Greater Than or Greater Than Or Equal. Instead the comp=
arison is reordered so that the operands are swapped and a Less Than or a L=
ess Than Or Equal is performed. This is perfectly acceptable until you need=
 to determine whether the left or right operand&#39;s function needs to be =
called, such as with objects.</div><div>2. The fact that the signature uses=
 `mixed` for the typing removes a lot of the safety features the previous R=
FC had, and makes a lot of the concerns that stopped that RFC worse. In PHP=
 currently, an object used with any non-comparison operand results in a Typ=
eError. In the previous proposal, this behavior was preserved *even for obj=
ects which implement overloads* unless they specifically listed the type as=
 accepted in the overload definition. What this did is ensure that anything=
 OTHER than a TypeError guaranteed the developer that they were dealing wit=
h an operator overload that they could go inspect.</div><div>3. The private=
/protected distinction is fairly meaningless for the functions that impleme=
nt overloads, because the privacy of the function is ignored completely whe=
n it is executed to evaluate an operator.</div><div>4. The `static` distinc=
tion is also fairly meaningless, as in PHP there is no situation possible w=
here an operator overload can occur WITHOUT it operating on objects themsel=
ves.</div><div>5. Your voting choices actually constitute something that is=
 not allowed for RFCs. A &#39;yes&#39; vote allows operator overloads for G=
MP, a &#39;no&#39; vote changes GMP to `final`. There is no option here to =
leave PHP as it currently is, which is what a &#39;no&#39; vote should mean=
.</div><div>6. The `comparable` function you propose doesn&#39;t actually h=
ave an operator it corresponds to. There is no operator in PHP for &quot;is=
 the left value comparable with the right value&quot;. There are operators =
for comparisons themselves, which I assume you meant, but a bool is insuffi=
cient as a return type for that.</div><div><br></div><div>There&#39;s proba=
bly more, but this is a start for you to make some improvements and changes=
. However, I had to warn you before you put in too much effort that I am fa=
irly certain this RFC has very nearly zero chance of passing.</div><div><br=
></div><div>Jordan<br></div></div></div>

--0000000000001ed346061bf79290--