Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125471
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 07 Sep 2024 16:56:46 +0200
To: internals@lists.php.net
Message-ID: <37baa8a0-dfc1-4df3-97dc-64cceadd4d97@app.fastmail.com>
In-Reply-To: <0d461700-1b6c-44fd-9cda-aa698de49847@app.fastmail.com>
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>
Subject: Re: [PHP-DEV] bikeshed: Typed Aliases
Content-Type: multipart/alternative;
 boundary=493273da84a24ea1a94e921804a60bfb
From: rob@bottled.codes ("Rob Landers")

--493273da84a24ea1a94e921804a60bfb
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Sep 7, 2024, at 15:28, Larry Garfield wrote:
> On Fri, Sep 6, 2024, at 7:46 PM, Davey Shafik wrote:
>=20
> > My main struggle with this is readability. As much as I want custom=20
> > types (and type aliases is a good chunk of the way there), the main=20
> > issue I have is understanding what the valid inputs are:
> >
> > function foo(Status $string): void { }
> >
> > How do I know that Status is a) not a class, b) that I can fulfill t=
he=20
> > requirement with a string, and/or maybe any object with __toString()=
,=20
> > or maybe it=E2=80=99s ints? Or objects or enums?
> >
> > Even with file-local aliases (which I would definitely prefer to avo=
id)=20
> > we will most likely rely on developer tooling (e.g. IDEs and static=20
> > analyzers) to inform the developer what the right input types are.
> >
> > I would very much prefer to either go all in with an Enum-like (whic=
h=20
> > means that we can hang methods on to the value) or we need to=20
> > distinguish between type hints for class-likes and type hints for=20
> > not-class-likes (*Bar anyone?).
> >
> > Expanding on type-class-likes: within the type methods, $this->value=20
> > would refer to the original value, any operators would follow the=20
> > _same_ rules as either the original values type (e.g. $int =3D 4; $s=
tring=20
> >  =3D =E2=80=9Cfoo=E2=80=9D; $int . $string =3D=3D =E2=80=9C4foo", or=
 call __toString() in all the=20
> > normal places for strings if defined).
> >
> >
> > type Stringable: string|int {
> >      public function __toString(): string
> >      {
> >           return (string) $this->value; // original value
> >      }
> >
> >      // Add Stringable methods here
> > }.
>=20
> Methods on typedefs was the sort of "other stuff classes do" that I wa=
s trying to avoid getting into right now. :-)  Mainly because I can tota=
lly see how it's tempting, but also have no idea what it would mean from=
 a type-theoretic perspective.  It would only make sense if we're talkin=
g type DEFs, not type ALIASes.  I'm not against that, and it could be fu=
n to try and think through the type theoretical implications, but I don'=
t think that's what Rob was going for so I didn't want to take that side=
 quest just yet.  (Though if he's OK with it, I'm OK with it.)

To be fair, I should probably mention that I've already explored it some=
 (which I alluded to in another thread a couple of weeks ago). =F0=9F=98=
=89 So... I guess it is 'on-topic' for no other reason than it is intere=
sting.

Here are my notes thus far:

__Sugary Generics__

Since we could attach behaviors (at least at the engine level) we could =
use this to implement generics. Imagine we have a Box<T> and want to ins=
tantiate a Box<int|float>. To do this, when we define a Box<T>, we actua=
lly define an alias internally.

This is what the definition of our generic box class in PHP might look l=
ike:

class Box<T> { public T $var; }

It would get compiled to something like this (though it would probably b=
e invalid php, it perhaps illustrates my meaning):

class Box {
  public BoxT $var;
  public function __construct(private alias BoxT) {}
}

Then, to instantiate a Box<int|float >, the engine compiles the construc=
tor, passing the types as arguments (still probably not ever valid php) =
and stealing a bit from python's "self":

$box =3D new Box<int|float>; // compiles to $box =3D new Box(alias int|f=
loat);

The beauty of this is that it automatically becomes an error if you forg=
et the type argument (and if we made it the last argument, would allow s=
etting default values for BC reasons like Collection<T =3D mixed>)

Even constraints on T could be expressed similarly:

class Box<T: int|float> { public T $var; }

which may get compiled into this not ever valid php:

class Box {
  public BoxT $var;
  private alias BoxTConstraint =3D> int|float;
  public function __construct(private alias BoxT) {
    if (BoxT is not a BoxTConstraint) throw new RunTimeException();
}

Basically, it just needs to check that the BoxT alias is of the right ty=
pe during construction, essentially making generics just a sugary layer =
over aliases.

__Ambitious Type System Replacement__

I've also explored it in the case of types, in general, by replacing the=
 entire type system with this way of representing types (where a special=
 class represents a real type of value and its behavior). This would all=
ow for defining casting rules, operators, passing types as values (for p=
attern matching), etc on types themselves. I have no idea what that woul=
d look like "at scale", but it is interesting to think about because pri=
mitive types would have the same way of working as classes and everythin=
g else. It would also separate types from their implementation=E2=80=94w=
hether we want to expose this to user-land is a different story.=20

I suspect this could be a 'technical-only' change and not affect user-la=
nd at all. zvals would probably get a lot simpler though...=20

I generally stop myself from thinking too much about it, because while i=
nteresting, it is a TON of work. Not that I'm afraid of doing that work,=
 I just don't want to do it by myself. So, I'm cautiously optimistic as =
a >=3D9.0 type thing and finding the right people/support. I have no ide=
a how to do that, but I can at least try.

__Constraints__

Another exploration is that it would potentially allow for setting some =
constraints on raw values:

alias EmailAddress =3D> string {
  if (!is_valid_email($value)) throw new RuntimeException('not a valid e=
mail address');
}

However, I think there is a better solution for that (classes/structs/re=
cords/etc)... except for

__Typed Literals__

This could easily allow typed literals for value types. After all, a typ=
ed literal can be expressed as an alias over a type with a constraint.

__The Hammer and Screw Problem__

There are probably other use-cases by making the type-system more 'class=
-like', but I will say that PHP's class-system is quite robust=E2=80=94i=
f not as robust as its arrays=E2=80=94and should probably be relied on m=
ore. That being said, I've been working through this for a bit now, and =
it seems that I might be wielding this as a hammer and seeing nails ever=
ywhere, even when they are screws. So, while interesting, in many cases,=
 it probably isn't the best way to do things.

=E2=80=94 Rob
--493273da84a24ea1a94e921804a60bfb
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 Sat, Sep 7, 2024, at 15:28, Larry Garfield wrote:<br><=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Fri, Sep 6, =
2024, at 7:46 PM, Davey Shafik wrote:<br></div><div><br></div><div>&gt; =
My main struggle with this is readability. As much as I want custom&nbsp=
;<br></div><div>&gt; types (and type aliases is a good chunk of the way =
there), the main&nbsp;<br></div><div>&gt; issue I have is understanding =
what the valid inputs are:<br></div><div>&gt;<br></div><div>&gt; functio=
n foo(Status $string): void { }<br></div><div>&gt;<br></div><div>&gt; Ho=
w do I know that Status is a) not a class, b) that I can fulfill the&nbs=
p;<br></div><div>&gt; requirement with a string, and/or maybe any object=
 with __toString(),&nbsp;<br></div><div>&gt; or maybe it=E2=80=99s ints?=
 Or objects or enums?<br></div><div>&gt;<br></div><div>&gt; Even with fi=
le-local aliases (which I would definitely prefer to avoid)&nbsp;<br></d=
iv><div>&gt; we will most likely rely on developer tooling (e.g. IDEs an=
d static&nbsp;<br></div><div>&gt; analyzers) to inform the developer wha=
t the right input types are.<br></div><div>&gt;<br></div><div>&gt; I wou=
ld very much prefer to either go all in with an Enum-like (which&nbsp;<b=
r></div><div>&gt; means that we can hang methods on to the value) or we =
need to&nbsp;<br></div><div>&gt; distinguish between type hints for clas=
s-likes and type hints for&nbsp;<br></div><div>&gt; not-class-likes (*Ba=
r anyone?).<br></div><div>&gt;<br></div><div>&gt; Expanding on type-clas=
s-likes: within the type methods, $this-&gt;value&nbsp;<br></div><div>&g=
t; would refer to the original value, any operators would follow the&nbs=
p;<br></div><div>&gt; _same_ rules as either the original values type (e=
.g. $int =3D 4; $string&nbsp;<br></div><div>&gt;&nbsp; =3D =E2=80=9Cfoo=E2=
=80=9D; $int . $string =3D=3D =E2=80=9C4foo", or call __toString() in al=
l the&nbsp;<br></div><div>&gt; normal places for strings if defined).<br=
></div><div>&gt;<br></div><div>&gt;<br></div><div>&gt; type Stringable: =
string|int {<br></div><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public fun=
ction __toString(): string<br></div><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; {<br></div><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; return (string) $this-&gt;value; // original value<br></div=
><div>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br></div><div>&gt;<br></div><=
div>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // Add Stringable methods here<br=
></div><div>&gt; }.<br></div><div><br></div><div>Methods on typedefs was=
 the sort of "other stuff classes do" that I was trying to avoid getting=
 into right now. :-)&nbsp; Mainly because I can totally see how it's tem=
pting, but also have no idea what it would mean from a type-theoretic pe=
rspective.&nbsp; It would only make sense if we're talking type DEFs, no=
t type ALIASes.&nbsp; I'm not against that, and it could be fun to try a=
nd think through the type theoretical implications, but I don't think th=
at's what Rob was going for so I didn't want to take that side quest jus=
t yet.&nbsp; (Though if he's OK with it, I'm OK with it.)<br></div></blo=
ckquote><div><br></div><div>To be fair, I should probably mention that I=
've already explored it some (which I alluded to in another thread a cou=
ple of weeks ago). =F0=9F=98=89 So... I guess it is 'on-topic' for no ot=
her reason than it is interesting.<br></div><div><br></div><div>Here are=
 my notes thus far:</div><div><br></div><div>__Sugary Generics__</div><d=
iv><br></div><div>Since we could attach behaviors (at least at the engin=
e level) we could use this to implement generics. Imagine we have a Box&=
lt;T&gt; and want to instantiate a Box&lt;int|float&gt;. To do this, whe=
n we define a Box&lt;T&gt;, we actually define an alias internally.<br><=
/div><div><br></div><div>This is what the definition of our generic box =
class in PHP might look like:<br></div><div><br></div><div>class Box&lt;=
T&gt; { public T $var; }<br></div><div><br></div><div>It would get compi=
led to something like this (though it would probably be invalid php, it =
perhaps illustrates my meaning):<br></div><div><br></div><div>class Box =
{<br></div><div>&nbsp; public BoxT $var;<br></div><div>&nbsp; public fun=
ction __construct(private alias BoxT) {}</div><div>}<br></div><div><br><=
/div><div>Then, to instantiate a Box&lt;int|float &gt;, the engine compi=
les the constructor, passing the types as arguments (still probably not =
ever valid php) and stealing a bit from python's "self":<br></div><div><=
br></div><div>$box =3D new Box&lt;int|float&gt;; // compiles to $box =3D=
 new Box(alias int|float);<br></div><div><br></div><div>The beauty of th=
is is that it automatically becomes an error if you forget the type argu=
ment (and if we made it the last argument, would allow setting default v=
alues for BC reasons like Collection&lt;T =3D mixed&gt;)</div><div><br><=
/div><div>Even constraints on T could be expressed similarly:<br></div><=
div><br></div><div>class Box&lt;T: int|float&gt; { public T $var; }<br><=
/div><div><br></div><div>which may get compiled into this not ever valid=
 php:<br></div><div><br></div><div>class Box {<br></div><div>&nbsp; publ=
ic BoxT $var;<br></div><div>&nbsp; private alias BoxTConstraint =3D&gt; =
int|float;</div><div>&nbsp; public function __construct(private alias Bo=
xT) {<br></div><div>&nbsp; &nbsp; if (BoxT is not a BoxTConstraint) thro=
w new RunTimeException();<br></div><div>}</div><div><br></div><div>Basic=
ally, it just needs to check that the BoxT alias is of the right type du=
ring construction, essentially making generics just a sugary layer over =
aliases.<br></div><div><br></div><div>__Ambitious Type System Replacemen=
t__</div><div><br></div><div>I've also explored it in the case of types,=
 in general, by replacing the entire type system with this way of repres=
enting types (where a special class represents a real type of value and =
its behavior). This would allow for defining casting rules, operators, p=
assing types as values (for pattern matching), etc on types themselves. =
I have no idea what that would look like "at scale", but it is interesti=
ng to think about because primitive types would have the same way of wor=
king as classes and everything else. It would also separate types from t=
heir implementation=E2=80=94whether we want to expose this to user-land =
is a different story. <br></div><div><br></div><div>I suspect this could=
 be a 'technical-only' change and not affect user-land at all. zvals wou=
ld probably get a lot simpler though... <br></div><div><br></div><div>I =
generally stop myself from thinking too much about it, because while int=
eresting, it is a TON of work. Not that I'm afraid of doing that work, I=
 just don't want to do it by myself. So, I'm cautiously optimistic as a =
&gt;=3D9.0 type thing and finding the right people/support. I have no id=
ea how to do that, but I can at least try.<br></div><div><br></div><div>=
__Constraints__</div><div><br></div><div>Another exploration is that it =
would potentially allow for setting some constraints on raw values:<br><=
/div><div><br></div><div>alias EmailAddress =3D&gt; string {<br></div><d=
iv>&nbsp; if (!is_valid_email($value)) throw new RuntimeException('not a=
 valid email address');</div><div>}<br></div><div><br></div><div>However=
, I think there is a better solution for that (classes/structs/records/e=
tc)... except for<br></div><div><br></div><div><div>__Typed Literals__<b=
r></div><div><br></div><div>This could easily allow typed literals for v=
alue types. After all, a typed literal can be expressed as an alias over=
 a type with a constraint.<br></div><div><br></div><div>__The Hammer and=
 Screw Problem__<br></div><div><br></div><div>There are probably other u=
se-cases by making the type-system more 'class-like', but I will say tha=
t PHP's class-system is quite robust=E2=80=94if not as robust as its arr=
ays=E2=80=94and should probably be relied on more. That being said, I've=
 been working through this for a bit now, and it seems that I might be w=
ielding this as a hammer and seeing nails everywhere, even when they are=
 screws. So, while interesting, in many cases, it probably isn't the bes=
t way to do things.<br></div></div><div><br></div><div id=3D"sig12122915=
2">=E2=80=94 Rob<br></div></body></html>
--493273da84a24ea1a94e921804a60bfb--