Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125602
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 17 Sep 2024 22:37:01 +0200
To: internals@lists.php.net
Message-ID: <e4c478c5-03b5-4cfd-95c4-6161d88557fa@app.fastmail.com>
In-Reply-To: <0f0444eb-8fc5-4c56-8528-5aa528988e73@rwec.co.uk>
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>
Subject: Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)
Content-Type: multipart/alternative;
 boundary=a759e7aeb4b54eddb956bf25f6f7099c
From: rob@bottled.codes ("Rob Landers")

--a759e7aeb4b54eddb956bf25f6f7099c
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Sep 17, 2024, at 21:25, Rowan Tommins [IMSoP] wrote:
> On 17/09/2024 18:15, Jordan LeDoux wrote:
>>=20
>>> 1. Are we over-riding *operators* or *operations*? That is, is the u=
ser=20
>>> saying "this is what happens when you put a + symbol between two Foo=20
>>> objects", or "this is what happens when you add two Foo objects toge=
ther"?
>>=20
>> If we allow developers to define arbitrary code which is executed as =
a result of an operator, we will always end up allowing the first one.
>=20
>=20
> I don't think that's really true. Take the behaviour of comparisons in=
 your previous RFC: if that RFC had been accepted, the user would have h=
ad no way to make $a < $b and $a > $b have different behaviour, because =
the same overload would be called, with the same parameters, in both cas=
es.
>=20
> Slightly less strict is requiring groups of operators: the Haskell "nu=
m" typeclass (roughly similar to an interface) requires definitions for =
all of "+", "*", "abs", "signum", "fromInteger", and either unary or bin=
ary "-". It also defines the type signatures for each. If this was the o=
nly way to overload the "+" operator, users would have to really go out =
of their way to use it to mean something unrelated addition.
>=20
> As it happens, Haskell *does* allow arbitrary operator overloads, and =
in fact goes to the other extreme and allows entirely new operators to b=
e invented. The same is true in PostgreSQL - you can implement the <<//-=
^+^-//>>  operator if you want to.
>=20
> I think it's absolutely possible - and desirable - to choose a philoso=
phical position on that spectrum, and use it to drive design decisions. =
The choice of "__add" vs "operator+" is one such decision.
>=20
>=20
>=20
>> =20
>> The approach I plan to use for this question has a name: Polymorphic =
Handler Resolution. The overload that is executed will be decided by the=
 following series of decisions:
>>=20
>> 1. Are both of the operands objects? If not, use the overload on the =
one that is. (NOTE: if neither are objects, the new code will be bypasse=
d entirely, so I do not need to handle this case)
>> 2. If they are both objects, are they both instances of the same clas=
s? If they are, use the overload of the one on the left.
>> 3. If they are not objects of the same class, is one of them a direct=
 descendant of the other? If so, use the overload of the descendant.
>> 4. If neither of them are direct descendants of the other, use the ov=
erload of the object on the left. Does it produce a type error because i=
t does not accept objects of the type in the other position? Return the =
error and abort instead of re-trying by using the overload on the right.
>=20
>=20
> This is option (g) in my list, with the additional "prefer sub-classes=
" rule (step 3), which I agree would be a good addition.
>=20
> As noted, it doesn't provide symmetry, because step 4 depends on the o=
rder in the source code. Option (c) is the same algorithm without step 4=
, so guarantees that $a + $b and $b + $a will always call the same metho=
d.
>=20
> Options (d), (e), and (f) each add an extra step: one operand can sign=
al "I don't know" and the other operand gets a chance to answer. They're=
 essentially ways to "partially implement" an operator.
>=20
> Options (a) and (b) perform the same kind of polymorphic resolution on=
 *both* operands, which is how many languages work for functions and/or =
methods already.=20
>=20
>=20
>=20
> Reading the C# spec, if there is more than one candidate overload whic=
h is equally specific, an error is raised. I guess you could do the same=
 even with one implementation per class, by replacing step 4 in your alg=
orithm:
>=20
>=20
> > 4. If neither of them are direct descendants of the other, and only =
one implements the operator, use it.
> > 5. If neither of them are direct descendants of the other, and both =
implement the operator, throw an error.
>=20
> Let's call that option (h) :)
>=20
>=20
>=20
> By the way, searching online for the phrase "Polymorphic Handler Resol=
ution" finds no results other than you saying it is the name for this al=
gorithm.
>=20
>=20
>=20
>> This is similar to what I originally designed, and I actually moved t=
o an enum based on feedback. The argument was something like `$isReverse=
d` or `$left` or so on is somewhat ambiguous, while the enum makes it ex=
tremely explicit.
>=20
>=20
> Ah, fair enough. Explicitness vs conciseness is always a trade-off. My=
 thinking was that the "reversed" form would be far more rarely called t=
han the "normal" form; but that depends a lot on which resolution algori=
thm is used.
>=20
>=20
>=20
> Regards,
>=20
> --=20
> Rowan Tommins
> [IMSoP]

To be honest, this juggling of caller orders has me a bit concerned. For=
 example, matrix multiplication isn=E2=80=99t communitive, as are non-ab=
elion groups in general (quaternions being another popular system), but,=
 I am used to Scala, where the left-hand is the one always called.

I understand that this is what the operant position is for, but it strik=
es me as something that extreme care has to be called for when working w=
ith these types of objects when another object is involved. For example,=
 quaternions can be multiplied by a matrix and the order is super import=
ant (used for 3d rotations) but it appears the actual method called may =
not be deterministic because these classes may be unrelated, the one on =
the left is called, which may or may not result in a correct answer. All=
 that is to say, this is just to illustrate how complex this ordering al=
gorithm seems to be. Depending on how the libraries are implemented and =
whether they are designed to work together.=20

I would prefer to see something simple, and easy to reason about. We can=
 abuse some mathematical properties to result in something quite simple:

 1. If both are scalar, use existing logic.=20
 2. If one is scalar and the other is not, use existing logic.=20
 3. If one is scalar and the other overrides the operation, rearrange th=
e operation per its communitive rules so the object is on the left. $sca=
lar + $obj =3D=3D $obj + $scalar; $scalar - $obj =3D=3D -$obj + $scalar,=
 -($obj - $scalar). It is generally accepted (IIRC) that when scalars ar=
e involved, we don=E2=80=99t need to be concerned with non-abelion group=
s.
 4. If both are objects, use the one on the left.
I think this is much easier to reason about (you either get a scalar or =
another object) that doesn=E2=80=99t involve a developer deeply understa=
nding the inheritance of the objects in question or to understand the al=
gorithm for choosing which one will be called.=20

=E2=80=94 Rob
--a759e7aeb4b54eddb956bf25f6f7099c
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Tue, Sep 17, 2024, at 21:25, Rowan Tommins [IMSoP] wro=
te:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div class=3D=
"qt-moz-cite-prefix">On 17/09/2024 18:15, Jordan LeDoux=0A      wrote:<b=
r></div><blockquote type=3D"cite" cite=3D"mid:CAMrTa2FLJwjwy9uGpRJJJFMUD=
1vs=3Dvqzv8x2VxMsYeBqMN4m9Q@mail.gmail.com"><div dir=3D"ltr"><div><br></=
div><div class=3D"qt-gmail_quote"><blockquote class=3D"qt-gmail_quote" s=
tyle=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.=
8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204, 204, 204);padding-left:1ex;"><div>1. Are we over-riding *operators*=
 or *operations*? That is,=0A            is the user <br></div><div> say=
ing "this is what happens when you put a + symbol between=0A            =
two Foo <br></div><div> objects", or "this is what happens when you add =
two Foo=0A            objects together"?<br></div></blockquote><div><br>=
</div><div>If we allow developers to define arbitrary code which is=0A  =
          executed as a result of an operator, we will always end up=0A =
           allowing the first one.<br></div></div></div></blockquote><p>=
<br></p><p>I don't think that's really true. Take the behaviour of=0A   =
   comparisons in your previous RFC: if that RFC had been accepted,=0A  =
    the user would have had no way to make $a &lt; $b and $a &gt; $b=0A =
     have different behaviour, because the same overload would be=0A    =
  called, with the same parameters, in both cases.<br></p><p>Slightly le=
ss strict is requiring groups of operators: the=0A      Haskell "num" ty=
peclass (roughly similar to an interface) requires=0A      definitions f=
or all of "+", "*", "abs", "signum", "fromInteger",=0A      and either u=
nary or binary "-". It also defines the type=0A      signatures for each=
. If this was the only way to overload the "+"=0A      operator, users w=
ould have to really go out of their way to use it=0A      to mean someth=
ing unrelated addition.<br></p><p>As it happens, Haskell *does* allow ar=
bitrary operator overloads,=0A      and in fact goes to the other extrem=
e and allows entirely new=0A      operators to be invented. The same is =
true in PostgreSQL - you can=0A      implement the &lt;&lt;//-^+^-//&gt;=
&gt;&nbsp; operator if you want to.<br></p><p>I think it's absolutely po=
ssible - and desirable - to choose a=0A      philosophical position on t=
hat spectrum, and use it to drive=0A      design decisions. The choice o=
f "__add" vs "operator+" is one such=0A      decision.<br></p><p><br></p=
><blockquote type=3D"cite" cite=3D"mid:CAMrTa2FLJwjwy9uGpRJJJFMUD1vs=3Dv=
qzv8x2VxMsYeBqMN4m9Q@mail.gmail.com"><div dir=3D"ltr"><div class=3D"qt-g=
mail_quote"><div>&nbsp;<br></div><div>The approach I plan to use for thi=
s question has a name:=0A          Polymorphic Handler Resolution. The o=
verload that is executed=0A          will be decided by the following se=
ries of decisions:<br></div><div><br></div><div>1. Are both of the opera=
nds objects? If not, use the=0A            overload on the one that is. =
(NOTE: if neither are objects,=0A            the new code will be bypass=
ed entirely, so I do not need to=0A            handle this case)<br></di=
v><div>2. If they are both objects, are they both instances of=0A       =
     the same class? If they are, use the overload of the one on=0A     =
       the left.<br></div><div>3. If they are not objects of the same cl=
ass, is one of=0A            them a direct descendant of the other? If s=
o, use the=0A            overload of the descendant.<br></div><div>4. If=
 neither of them are direct descendants of the=0A            other, use =
the overload of the object on the left. Does it=0A            produce a =
type error because it does not accept objects of=0A            the type =
in the other position? Return the error and abort=0A            instead =
of re-trying by using the overload on the right.<br></div></div></div></=
blockquote><p><br></p><p>This is option (g) in my list, with the additio=
nal "prefer=0A      sub-classes" rule (step 3), which I agree would be a=
 good=0A      addition.<br></p><p>As noted, it doesn't provide symmetry,=
 because step 4 depends on=0A      the order in the source code. Option =
(c) is the same algorithm=0A      without step 4, so guarantees that $a =
+ $b and $b + $a will always=0A      call the same method.<br></p><p>Opt=
ions (d), (e), and (f) each add an extra step: one operand can=0A      s=
ignal "I don't know" and the other operand gets a chance to=0A      answ=
er. They're essentially ways to "partially implement" an=0A      operato=
r.<br></p><p>Options (a) and (b) perform the same kind of polymorphic=0A=
      resolution on *both* operands, which is how many languages work=0A=
      for functions and/or methods already.&nbsp;<br></p><p><br></p><p>R=
eading the C# spec, if there is more than one candidate overload=0A     =
 which is equally specific, an error is raised. I guess you could=0A    =
  do the same even with one implementation per class, by replacing=0A   =
   step 4 in your algorithm:<br></p><p></p><div>&gt; 4. If neither of th=
em are direct descendants of the other,=0A      and only one implements =
the operator, use it.<br></div><div> &gt; 5. If neither of them are dire=
ct descendants of the other,=0A      and both implement the operator, th=
row an error.<br></div><p></p><p>Let's call that option (h) :)<br></p><p=
><br></p><p>By the way, searching online for the phrase "Polymorphic Han=
dler=0A      Resolution" finds no results other than you saying it is th=
e name=0A      for this algorithm.<br></p><p><br></p><blockquote type=3D=
"cite" cite=3D"mid:CAMrTa2FLJwjwy9uGpRJJJFMUD1vs=3Dvqzv8x2VxMsYeBqMN4m9Q=
@mail.gmail.com"><div dir=3D"ltr"><div class=3D"qt-gmail_quote"><div>Thi=
s is similar to what I originally designed, and I=0A            actually=
 moved to an enum based on feedback. The argument=0A            was some=
thing like `$isReversed` or `$left` or so on is=0A            somewhat a=
mbiguous, while the enum makes it extremely=0A            explicit.<br><=
/div></div></div></blockquote><p><br></p><p>Ah, fair enough. Explicitnes=
s vs conciseness is always a=0A      trade-off. My thinking was that the=
 "reversed" form would be far=0A      more rarely called than the "norma=
l" form; but that depends a lot=0A      on which resolution algorithm is=
 used.<br></p><p><br></p><p>Regards,<br></p><pre class=3D"qt-moz-signatu=
re" cols=3D"72">--=20=0ARowan Tommins=0A[IMSoP]<br></pre></blockquote><d=
iv><br></div><div>To be honest, this juggling of caller orders has me a =
bit concerned. For example, matrix multiplication isn=E2=80=99t communit=
ive, as are non-abelion groups in general (quaternions being another pop=
ular system), but, I am used to Scala, where the left-hand is the one al=
ways called.<br></div><div><br></div><div>I understand that this is what=
 the operant position is for, but it strikes me as something that extrem=
e care has to be called for when working with these types of objects whe=
n another object is involved. For example, quaternions can be multiplied=
 by a matrix and the order is super important (used for 3d rotations) bu=
t it appears the actual method called may not be deterministic because t=
hese classes may be unrelated, the one on the left is called, which may =
or may not result in a correct answer. All that is to say, this is just =
to illustrate how complex this ordering algorithm seems to be. Depending=
 on how the libraries are implemented and whether they are designed to w=
ork together.&nbsp;<br></div><div><br></div><div>I would prefer to see s=
omething simple, and easy to reason about. We can abuse some mathematica=
l properties to result in something quite simple:<br></div><div><br></di=
v><ol><li>If both are scalar, use existing logic.&nbsp;<br></li><li>If o=
ne is scalar and the other is not, use existing logic.&nbsp;<br></li><li=
>If one is scalar and the other overrides the operation, rearrange the o=
peration per its communitive rules so the object is on the left. $scalar=
 + $obj =3D=3D $obj + $scalar; $scalar - $obj =3D=3D -$obj + $scalar, -(=
$obj - $scalar). It is generally accepted (IIRC) that when scalars are i=
nvolved, we don=E2=80=99t need to be concerned with non-abelion groups.<=
br></li><li>If both are objects, use the one on the left.<br></li></ol><=
div>I think this is much easier to reason about (you either get a scalar=
 or another object) that doesn=E2=80=99t involve a developer deeply unde=
rstanding the inheritance of the objects in question or to understand th=
e algorithm for choosing which one will be called.&nbsp;</div><div><br><=
/div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--a759e7aeb4b54eddb956bf25f6f7099c--