Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125488
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 10 Sep 2024 10:31:59 +0200
To: "Mike Schinkel" <mike@newclarity.net>,
 "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Message-ID: <f8b74d3f-a0fe-4e45-82ac-1bc56cb02cea@app.fastmail.com>
In-Reply-To: <50CFF539-AD22-4F89-A65E-77AF76DBD63A@newclarity.net>
References: <0fa39535-f22d-4eba-b4df-90abe39e683a@app.fastmail.com>
 <e73be2b0-faa9-42eb-a9f6-8308cf4f8c94@app.fastmail.com>
 <ed3847bf-af2e-4e33-ac09-66e44696fdeb@app.fastmail.com>
 <79e58673-50ec-461e-a998-736b020e4287@app.fastmail.com>
 <a3cd6d90-cfac-40d5-a59a-c9f6d9dbe5f0@app.fastmail.com>
 <928A2984-6035-4DA6-9EA7-12E85237C270@php.net>
 <0d461700-1b6c-44fd-9cda-aa698de49847@app.fastmail.com>
 <667233C2-BC47-4530-8142-D90E6907FE63@daveyshafik.com>
 <D95D21CE-45AB-487A-B59D-40305C0C569D@rwec.co.uk>
 <63d241a8-a34a-498c-a5f9-f34230aa5afa@app.fastmail.com>
 <4C7A7F27-B787-44CA-B664-CEF4B9B412FB@newclarity.net>
 <212fd466-85bc-4447-90b7-8fe5426d1bd1@rwec.co.uk>
 <50CFF539-AD22-4F89-A65E-77AF76DBD63A@newclarity.net>
Subject: Re: [PHP-DEV] bikeshed: Typed Aliases
Content-Type: multipart/alternative;
 boundary=5d1189d20ecf416682d85417012414b4
From: rob@bottled.codes ("Rob Landers")

--5d1189d20ecf416682d85417012414b4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 10, 2024, at 10:00, Mike Schinkel wrote:
>> On Sep 9, 2024, at 5:35 PM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.=
uk> wrote:
>>=20
>> On 09/09/2024 19:41, Mike Schinkel wrote:
>>> In Go you cannot add or subtract on a typedef without casting to the=20
>>> underlying type.  I would definitely prefer that to be relaxed, but =
only
>>>  if it is relaxed via an explicit opt-in, e.g. something maybe like=20
>>> this:
>>>=20
>>> typedef UserId: int operations: +, -, *, /;
>>> typedef UserName: string operations: .;
>> I think this would stray into some of the same complexity as operator=
 overloads on objects, in terms of the types and values allowed. For ins=
tance:
>>=20
> I tend to agree that allowing operations may be too much for an initia=
l scope given that it is unlike anything else in the current language an=
d with no other languages offering an equivalent AFAIK.
>=20
> I would however make the distinction that it is unlike operator overlo=
ading because the big concern was what constituted an operation for any =
given type could be too subjective.  In your example of `Metres` it is p=
retty obvious, but not at all obvious for a `User`, for example.  (BTW, =
thank you for not calling out my nonsensical example of operations on a =
`UserId`; when I wrote that I clear was not thinking about if they were =
relevant, doh!)
>=20
> However give the suggestion regarding operations with a typedef, the o=
nly operations that I suggested would be valid would be the ones already=
 defined on the underlying type, (when I mentioned other operations I wa=
s thinking of methods =E2=80=94 see my the following example with round =
=E2=80=94 not operators so that is not the same as operator overload.) F=
or example:
>=20
> /**
>  * Currency is an int so for example in USD 1=20
>  * unit of currency not a dollar but a cent.
>  */
> typedef Currency: int operations: +,-,*,/,round;
> function CalcTotal(Currency $subTotal, Currency $shipping, float $tax)=
:Currency {
>    return round($subTotal*(1+$tax/100),0) + $shipping;
> }

This is very similar (behaviorally) to what I wanted to do with GMP. Ove=
rloading GMP would have given you int-like powers in your type. The bigg=
est negative feedback I got was that people would abuse it still; so we =
need some way to prevent abuse. If you read Jordon's operator overloads =
RFC, and my GMP overloading RFC, you can see that users basically need a=
 way to define how to operate over even just an integer.

For example, Dollar(1) + Euro(3) is what? Or even Dollar(1) + 1? How doe=
s a developer prevent someone from doing something nonsensical? The lang=
uage needs to enforce some rules and/or the developer needs to be able t=
o define them. These rules need to be intuitive and well reasoned, IMHO.

>> typedef Metres: int;
>>=20
>> assert( Metres(2) +  Metres(1) =3D=3D=3D Metres(3) ); // most obvious
>> assert( Metres(2) + 1 =3D=3D=3D Metres(3) ); // seems pretty clear
>=20
> Both of those are in line with what I was suggesting.
>>=20
>>=20
>> $_GET['input'] =3D '1';
>> assert( Metres(2) + $_GET['input'] =3D=3D=3D Metres(3) ); // might be=
 more controversial
>>=20
>>=20
> I would not consider this appropriate as it has two levels of conversi=
on and could thus end up with unintended edge cases. To do the above I t=
hink you would have to either convert or typecast:
>=20
> assert( Metres(2) + intval($_GET['input']) =3D=3D=3D Metres(3) );=20
> assert( Metres(2) + (int)$_GET['input'] =3D=3D=3D Metres(3) );=20
>>=20
>>=20
>> typedef Feet: int;
>> assert( Metres(2) + Feet(1) =3D=3D=3D Metres(3) ); // almost certainl=
y a bad idea
>>=20
>>=20
> This would be operator overloading where knowledge of the conversion b=
etween meters and feet would be required, and that is not in any way in =
scope with what I was suggesting. =20
>=20
> As an aside, I am against userland operator overloading as I have seen=
 in other languages that operator overloading gets abused and results in=
 code that is a nightmare to maintain. OTOH, I would support operator ov=
erloading in specific cases, e.g. a `Measurement` class in PHP core coul=
d allow adding meters to feet, assuming such a proposal were made and al=
l other aspects of the RFC were of the nature to be voted in.
>=20
> To reiterate on typedefs, what I was suggesting was that if an operati=
on was explicitly allowed =E2=80=94 e.g. + =E2=80=94 then anything that =
would work with the underlying type =E2=80=94 such as adding an int 1 wo=
uld work without typecasting and yet still result in the typedef type, e=
.g. Meters(2) + 1 results in a value of type Meters. (note that I correc=
ted your spelling of 'Meters' here. ;-)=20
>=20
> But I agree, this is probably a bridge too far for a first RFC for typ=
edefs.=20
>=20
>>> type MyNewType: Foo
>>> type MyAlias =3D Foo
>> I know this was only an example, but as a general point, I think we s=
hould avoid concise but cryptic differences like this. PHP is generally =
keyword-heavy, rather than punctuation-heavy, and I think that's a valid=
 style which we should keep to.
>>=20
> Here, I also tend to agree WRT PHP.  Was just pointing out for sake of=
 laying out other options that were implied not to exist.
>=20
> -Mike

In other news, I'm highly considering refactoring the records RFC to be =
a typedef RFC; the infrastructure is there; we just need more restrictio=
ns.

=E2=80=94 Rob
--5d1189d20ecf416682d85417012414b4
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}=0Ap.MsoNormal,p.MsoNoSpacing{margin:0}</=
style></head><body><div>On Tue, Sep 10, 2024, at 10:00, Mike Schinkel wr=
ote:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D"overflow-wrap=
:break-word;"><div><blockquote type=3D"cite" class=3D"qt-"><div class=3D=
"qt-">On Sep 9, 2024, at 5:35 PM, Rowan Tommins [IMSoP] &lt;<a href=3D"m=
ailto:imsop.php@rwec.co.uk" class=3D"qt-">imsop.php@rwec.co.uk</a>&gt; w=
rote:<br></div><div><br></div><div class=3D"qt-"><div class=3D"qt-"><div=
 class=3D"qt-moz-cite-prefix">On 09/09/2024 19:41, Mike Schinkel=0A     =
 wrote:<br></div><blockquote type=3D"cite" cite=3D"mid:4C7A7F27-B787-44C=
A-B664-CEF4B9B412FB@newclarity.net" class=3D"qt-"><pre class=3D"qt-">In =
Go you cannot add or subtract on a typedef without casting to the=20=0Au=
nderlying type.  I would definitely prefer that to be relaxed, but only=0A=
 if it is relaxed via an explicit opt-in, e.g. something maybe like=20=0A=
this:=0A=0Atypedef UserId: int operations: +, -, *, /;=0Atypedef UserNam=
e: string operations: .;<br></pre></blockquote><p class=3D"qt-">I think =
this would stray into some of the same complexity as=0A      operator ov=
erloads on objects, in terms of the types and values=0A      allowed. Fo=
r instance:<br></p></div></div></blockquote><div>I tend to agree that al=
lowing operations may be too much for an initial scope given that it is =
unlike anything else in the current language and with no other languages=
 offering an equivalent AFAIK.<br></div><div><br></div><div>I would howe=
ver make the distinction that it is unlike operator overloading because =
the big concern was what constituted an operation for any given type cou=
ld be too subjective. &nbsp;In your example of `Metres` it is pretty obv=
ious, but not at all obvious for a `User`, for example. &nbsp;(BTW, than=
k you for not calling out my nonsensical example of operations on a `Use=
rId`; when I wrote that I clear was not thinking about if they were rele=
vant, doh!)<br></div><div><br></div><div>However give the suggestion reg=
arding operations with a typedef, the only operations that I suggested w=
ould be valid would be the ones already defined on the underlying type, =
(when I mentioned other operations I was thinking of methods =E2=80=94 s=
ee my the following example with round =E2=80=94 not operators so that i=
s not the same as operator overload.) For example:<br></div><div><br></d=
iv><div class=3D"qt-"><div class=3D"qt-"><span class=3D"color" style=3D"=
color:rgb(0, 0, 0);"><span style=3D"" class=3D"qt-">/**<br class=3D"qt-"=
>&nbsp;* Currency is an int so for example in USD 1&nbsp;<br class=3D"qt=
-">&nbsp;* unit of currency not a dollar but a cent.<br class=3D"qt-">&n=
bsp;*/<br class=3D"qt-">typedef&nbsp;Currency:&nbsp;int&nbsp;operations:=
 +,-,*,/,round;<br class=3D"qt-">function&nbsp;CalcTotal(Currency&nbsp;$=
subTotal,&nbsp;Currency&nbsp;$shipping,&nbsp;float&nbsp;$tax):Currency&n=
bsp;{<br class=3D"qt-">&nbsp; &nbsp;return&nbsp;round($subTotal*(1+$tax/=
100),0) +&nbsp;$shipping;<br class=3D"qt-">}</span></span></div></div></=
div></blockquote><div><br></div><div>This is very similar (behaviorally)=
 to what I wanted to do with GMP. Overloading GMP would have given you i=
nt-like powers in your type. The biggest negative feedback I got was tha=
t people would abuse it still; so we need some way to prevent abuse. If =
you read Jordon's operator overloads RFC, and my GMP overloading RFC, yo=
u can see that users basically need a way to define how to operate over =
even just an integer.<br></div><div><br></div><div>For example, Dollar(1=
) + Euro(3) is what? Or even Dollar(1) + 1? How does a developer prevent=
 someone from doing something nonsensical? The language needs to enforce=
 some rules and/or the developer needs to be able to define them. These =
rules need to be intuitive and well reasoned, IMHO.</div><div><br></div>=
<blockquote type=3D"cite" id=3D"qt" style=3D"overflow-wrap:break-word;">=
<div><blockquote type=3D"cite" class=3D"qt-"><div class=3D"qt-"><div cla=
ss=3D"qt-"><p class=3D"qt-">typedef Metres: int;<br></p><div>assert( Met=
res(2) +&nbsp; Metres(1) =3D=3D=3D Metres(3) ); // most obvious<br></div=
><div>assert( Metres(2) + 1 =3D=3D=3D Metres(3) ); // seems pretty clear=
<br></div></div></div></blockquote><div><br></div><div>Both of those are=
 in line with what I was suggesting.<br></div><blockquote type=3D"cite" =
class=3D"qt-"><div class=3D"qt-"><div class=3D"qt-"><p class=3D"qt-"><br=
></p><div>$_GET['input'] =3D '1';<br></div><div>assert( Metres(2) + $_GE=
T['input'] =3D=3D=3D Metres(3) ); // might be=0A      more controversial=
<br></div><p><br></p></div></div></blockquote><div>I would not consider =
this appropriate as it has two levels of conversion and could thus end u=
p with unintended edge cases. To do the above I think you would have to =
either convert or typecast:<br></div></div><div><br></div><div>assert( M=
etres(2) + intval($_GET['input']) =3D=3D=3D Metres(3) );&nbsp;<br></div>=
<div>assert( Metres(2) + (int)$_GET['input'] =3D=3D=3D Metres(3) );&nbsp=
;<br></div><div><blockquote type=3D"cite" class=3D"qt-"><div class=3D"qt=
-"><div class=3D"qt-"><p class=3D"qt-"><br></p><div>typedef Feet: int;<b=
r></div><div>assert( Metres(2) + Feet(1) =3D=3D=3D Metres(3) ); // almos=
t certainly a=0A      bad idea<br></div><p><br></p></div></div></blockqu=
ote><div>This would be operator overloading where knowledge of the conve=
rsion between meters and feet would be required, and that is not in any =
way in scope with what I was suggesting. &nbsp;<br></div></div><div><br>=
</div><div>As an aside, I am against userland operator overloading as I =
have seen in other languages that operator overloading gets abused and r=
esults in code that is a nightmare to maintain. OTOH, I would support op=
erator overloading in specific cases, e.g. a `Measurement` class in PHP =
core could allow adding meters to feet, assuming such a proposal were ma=
de and all other aspects of the RFC were of the nature to be voted in.<b=
r></div><div><br></div><div>To reiterate on typedefs, what I was suggest=
ing was that if an operation was explicitly allowed =E2=80=94 e.g. + =E2=
=80=94 then anything that would work with the underlying type =E2=80=94 =
such as adding an int 1 would work without typecasting and yet still res=
ult in the typedef type, e.g. Meters(2) + 1 results in a value of type M=
eters. (note that I corrected your spelling of 'Meters' here. ;-)&nbsp;<=
br></div><div><br></div><div>But I agree, this is probably a bridge too =
far for a first RFC for typedefs.&nbsp;<br></div><div><div><br></div><bl=
ockquote type=3D"cite" class=3D"qt-"><div class=3D"qt-"><div class=3D"qt=
-"><blockquote type=3D"cite" class=3D"qt-"><pre class=3D"qt-moz-quote-pr=
e">type MyNewType: Foo=0Atype MyAlias =3D Foo<br></pre></blockquote><p c=
lass=3D"qt-">I know this was only an example, but as a general point, I =
think=0A      we should avoid concise but cryptic differences like this.=
 PHP is=0A      generally keyword-heavy, rather than punctuation-heavy, =
and I=0A      think that's a valid style which we should keep to.<br></p=
></div></div></blockquote><div>Here, I also tend to agree WRT PHP. &nbsp=
;Was just pointing out for sake of laying out other options that were im=
plied not to exist.<br></div></div><div><br></div><div>-Mike<br></div></=
blockquote><div><br></div><div>In other news, I'm highly considering ref=
actoring the records RFC to be a typedef RFC; the infrastructure is ther=
e; we just need more restrictions.</div><div><br></div><div id=3D"sig121=
229152">=E2=80=94 Rob<br></div></body></html>
--5d1189d20ecf416682d85417012414b4--