Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125460
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 07 Sep 2024 01:27:47 +0200
To: internals@lists.php.net
Message-ID: <ed3847bf-af2e-4e33-ac09-66e44696fdeb@app.fastmail.com>
In-Reply-To: <e73be2b0-faa9-42eb-a9f6-8308cf4f8c94@app.fastmail.com>
References: <0fa39535-f22d-4eba-b4df-90abe39e683a@app.fastmail.com>
 <e73be2b0-faa9-42eb-a9f6-8308cf4f8c94@app.fastmail.com>
Subject: Re: [PHP-DEV] bikeshed: Typed Aliases
Content-Type: multipart/alternative;
 boundary=0ec32c13434c4e64ac0d17a3a7eab4e8
From: rob@bottled.codes ("Rob Landers")

--0ec32c13434c4e64ac0d17a3a7eab4e8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 6, 2024, at 22:45, Larry Garfield wrote:
> Hi Rob.
>=20
> First of all, I'm very much in favor of type aliases generally, so tha=
nk you for taking a swing at this.
>=20
> Second, it looks like you've run into the main design issue that has a=
lways prevented them in the past: Should aliases be file-local and thus =
not reusable, or global and thus we need to figure out autoloading for t=
hem?  It looks like your answer to that question at the moment is "yes".=
 :-)  While I can see the appeal, I don't think that's the best approach=
.  Or rather, if we go that route, they shouldn't be quite so similar sy=
ntactically.
>=20
> There seems to be two different implementations living in the same RFC=
, uncomfortably.  In one, it's a compiler-time replacement.  In the othe=
r, it's a special class-like.  But the RFC seems to go back and forth on=
 what happens in which case, and I'm not sure which is which.
>=20
> However, you have demonstrated a working class-like for it, which is f=
rankly the biggest hurdle.  So I think the direction has promise, but sh=
ould be adjusted to go all-in on that approach.
>=20
> To wit:
>=20
> typealias Stringy: string|Stringable;
> typealias UserID: Int;
> typealias TIme: Hour|Minute|Second;
> typealias FilterCallback: callable(mixed $a): bool;  (eventually...)
>=20
> (etc.)
>=20
> Each of those produces a class-like, which can therefore be autoloaded=
 like a class.  The syntax is also a bit closer to a class (or an Enum, =
I suppose), so it's much more self-evident that they are defining a reus=
able thing (whereas "use" does not do that currently).  And the syntax i=
s not stringy, like the proposed type_alias(), so it's easier to write. =
 I wouldn't even include type_alias() at that point.  It exists at runti=
me, so reflection is meaningful.
>=20
> Aliases can then be used only in parameter, return, property, and inst=
anceof types.  Extends and implements are out of scope entirely.
>=20
> (Whether the keyword is typealias or typedef, uses : or =3D, or whatev=
er, is its own bikeshed I won't dive into at the moment.)
>=20
> Then, as a separate, entirely optional, maybe even separate RFC (or se=
cond vote, or whatever), we have a `use string|Stringable as Stringy` sy=
ntax.  Like all other `use` declarations, these are compile-time only, s=
ingle-file only, and do not exist at runtime, so no reflection.  They co=
mpile away just like all other use-statements now.
>=20
> I'm not personally convinced the second is really necessary if we do a=
 good enough job on the first, but I'd probably not stand in the way of =
having both.

That's a really good point and would clear up quite a bit of confusion a=
nd complexity.

>=20
> Having typealias/typedef as a class-like also opens up some interestin=
g potential in the future, because classes have all sorts of other thing=
s they do, but that is probably too complex scope creepy to get into her=
e so I will not go further than that mention.
>=20
> I suspect there's also other edge case bits to worry about, particular=
ly if trying to combine a complex alias with a complex type, which could=
 lead to violating the DNF rule.  For example:

Oh, DNF is the bane of my existence with this RFC=E2=80=94I don't want t=
o mess this up. I'll see you at the end of the example, though.

>=20
> typealias Foo: (Bar&Baz)|Beep;
>=20
> use (Bar&Baz)|Beep as Foo;
>=20
> function narf(Foo&Stringable $s) {}
>=20
> With the compile time approach, that would expand to `(Bar&Baz)|Beep&S=
tringable`, which is not a valid type def.

I can see how you arrived at this, but I think you may have missed a ste=
p, since the entirety of Foo will be &'d with Stringable.

Foo =3D (Bar & Baz) | Beep

want: (Foo) & Stringable

expand Foo: ((Bar & Baz) | Beep) & Stringable

Which can be reduced to the following in proper DNF (at least, it compil=
es=E2=80=94https://3v4l.org/0bMlP):

(Beep & Stringable) | (Bar & Baz & Stringable)

It's probably a good idea to update the RFC explaining how expansion wor=
ks.

>=20
> With the runtime approach, I don't know if that could be handled grace=
fully or if it would still cause an error.
>=20
> I'm not sure what the right solution is on this one, just pointing it =
out as a thing to resolve.
>=20
> --Larry Garfield
>=20

=E2=80=94 Rob
--0ec32c13434c4e64ac0d17a3a7eab4e8
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>On Fri, Sep 6, =
2024, at 22:45, Larry Garfield wrote:<br></div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><div>Hi Rob.<br></div><div><br></div><div>First of=
 all, I'm very much in favor of type aliases generally, so thank you for=
 taking a swing at this.<br></div><div><br></div><div>Second, it looks l=
ike you've run into the main design issue that has always prevented them=
 in the past: Should aliases be file-local and thus not reusable, or glo=
bal and thus we need to figure out autoloading for them?&nbsp; It looks =
like your answer to that question at the moment is "yes". :-)&nbsp; Whil=
e I can see the appeal, I don't think that's the best approach.&nbsp; Or=
 rather, if we go that route, they shouldn't be quite so similar syntact=
ically.<br></div><div><br></div><div>There seems to be two different imp=
lementations living in the same RFC, uncomfortably.&nbsp; In one, it's a=
 compiler-time replacement.&nbsp; In the other, it's a special class-lik=
e.&nbsp; But the RFC seems to go back and forth on what happens in which=
 case, and I'm not sure which is which.<br></div><div><br></div><div>How=
ever, you have demonstrated a working class-like for it, which is frankl=
y the biggest hurdle.&nbsp; So I think the direction has promise, but sh=
ould be adjusted to go all-in on that approach.<br></div><div><br></div>=
<div>To wit:<br></div><div><br></div><div>typealias Stringy: string|Stri=
ngable;<br></div><div>typealias UserID: Int;<br></div><div>typealias TIm=
e: Hour|Minute|Second;<br></div><div>typealias FilterCallback: callable(=
mixed $a): bool;&nbsp; (eventually...)<br></div><div><br></div><div>(etc=
.)<br></div><div><br></div><div>Each of those produces a class-like, whi=
ch can therefore be autoloaded like a class.&nbsp; The syntax is also a =
bit closer to a class (or an Enum, I suppose), so it's much more self-ev=
ident that they are defining a reusable thing (whereas "use" does not do=
 that currently).&nbsp; And the syntax is not stringy, like the proposed=
 type_alias(), so it's easier to write.&nbsp; I wouldn't even include ty=
pe_alias() at that point.&nbsp; It exists at runtime, so reflection is m=
eaningful.<br></div><div><br></div><div>Aliases can then be used only in=
 parameter, return, property, and instanceof types.&nbsp; Extends and im=
plements are out of scope entirely.<br></div><div><br></div><div>(Whethe=
r the keyword is typealias or typedef, uses : or =3D, or whatever, is it=
s own bikeshed I won't dive into at the moment.)<br></div><div><br></div=
><div>Then, as a separate, entirely optional, maybe even separate RFC (o=
r second vote, or whatever), we have a `use string|Stringable as Stringy=
` syntax.&nbsp; Like all other `use` declarations, these are compile-tim=
e only, single-file only, and do not exist at runtime, so no reflection.=
&nbsp; They compile away just like all other use-statements now.<br></di=
v><div><br></div><div>I'm not personally convinced the second is really =
necessary if we do a good enough job on the first, but I'd probably not =
stand in the way of having both.<br></div></blockquote><div><br></div><d=
iv>That's a really good point and would clear up quite a bit of confusio=
n and complexity.<br></div><div><br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div><br></div><div>Having typealias/typedef as a class-=
like also opens up some interesting potential in the future, because cla=
sses have all sorts of other things they do, but that is probably too co=
mplex scope creepy to get into here so I will not go further than that m=
ention.<br></div><div><br></div><div>I suspect there's also other edge c=
ase bits to worry about, particularly if trying to combine a complex ali=
as with a complex type, which could lead to violating the DNF rule.&nbsp=
; For example:<br></div></blockquote><div><br></div><div>Oh, DNF is the =
bane of my existence with this RFC=E2=80=94I don't want to mess this up.=
 I'll see you at the end of the example, though.<br></div><div><br></div=
><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>type=
alias Foo: (Bar&amp;Baz)|Beep;<br></div><div><br></div><div>use (Bar&amp=
;Baz)|Beep as Foo;<br></div><div><br></div><div>function narf(Foo&amp;St=
ringable $s) {}<br></div><div><br></div><div>With the compile time appro=
ach, that would expand to `(Bar&amp;Baz)|Beep&amp;Stringable`, which is =
not a valid type def.<br></div></blockquote><div><br></div><div>I can se=
e how you arrived at this, but I think you may have missed a step, since=
 the entirety of Foo will be &amp;'d with Stringable.<br></div><div><br>=
</div><div>Foo =3D (Bar &amp; Baz) | Beep<br></div><div><br></div><div>w=
ant: (Foo) &amp; Stringable<br></div><div><br></div><div>expand Foo: ((B=
ar &amp; Baz) | Beep) &amp; Stringable<br></div><div><br></div><div>Whic=
h can be reduced to the following in proper DNF (at least, it compiles=E2=
=80=94<a href=3D"https://3v4l.org/0bMlP">https://3v4l.org/0bMlP</a>):<br=
></div><div><br></div><div>(Beep &amp; Stringable) | (Bar &amp; Baz &amp=
; Stringable)<br></div><div><br></div><div>It's probably a good idea to =
update the RFC explaining how expansion works.<br></div><div><br></div><=
blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>With t=
he runtime approach, I don't know if that could be handled gracefully or=
 if it would still cause an error.<br></div><div><br></div><div>I'm not =
sure what the right solution is on this one, just pointing it out as a t=
hing to resolve.<br></div><div><br></div><div>--Larry Garfield<br></div>=
<div><br></div></blockquote><div><br></div><div id=3D"sig121229152">=E2=80=
=94 Rob<br></div></body></html>
--0ec32c13434c4e64ac0d17a3a7eab4e8--