Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125459
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 06 Sep 2024 15:45:39 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <e73be2b0-faa9-42eb-a9f6-8308cf4f8c94@app.fastmail.com>
In-Reply-To: <0fa39535-f22d-4eba-b4df-90abe39e683a@app.fastmail.com>
References: <0fa39535-f22d-4eba-b4df-90abe39e683a@app.fastmail.com>
Subject: Re: [PHP-DEV] bikeshed: Typed Aliases
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Sep 6, 2024, at 1:41 PM, Rob Landers wrote:
> Hello Internals,
>
> I'm going to try something new. I've been working on another RFC calle=
d=20
> "Typed Aliases" (https://wiki.php.net/rfc/typed-aliases). It is very=20
> much a draft and in-flux, and I've already worked out the technical=20
> mechanics of it ... however, I am very unhappy with the syntax, and=20
> while I have a few ideas about that; I assume this list will be much=20
> better at it than me. So, please bring your brushes and paint; I=20
> brought a bikeshed.
>
> If you haven't read it already, here's the TL;DR:
>
> - This RFC expands the "use ... as ..." syntax to allow any type=20
> expression on the left side. These aliases are PER FILE and expire onc=
e=20
> the file is compiled.
>
> - This RFC also adds the ability for an alias to survive a file=20
> (currently using the "as alias" syntax that I don't like) which=20
> actually just creates a special kind of class. When this special class=20
> is encountered during type-checking, the alias is expanded and checked=
.=20
> It also allows this via a "type_alias()" function instead of the "use=20
> ... as alias ..." syntax.
>
> How it works:
>
> use string as alias MyString
>
> gets virtually compiled into a special class that would look something=20
> like this to ReflectionClass (as it is currently):
>
> class MyString extends PrimitiveAlias {=20
>   const PrimitiveType aliasOf =3D PrimitiveType::string;
> }
>
> - Reflection is a bit weird here, and I'm not exactly happy with it;=20
> but I'm curious what the list thinks. I'm open to virtually anything=20
> that makes sense here; including not allowing ReflectionClass on the=20
> type aliases at all.
>
> - Since these are "technically" classes, I went with just "use"-ing=20
> them like normal classes. Originally, I had something different: "use=20
> alias ..." (like "use function ...") to make it more clear. I will=20
> probably go back to this, but I'm curious what others think.
>
> I'm going to take a step back and listen/answer questions. But please,=20
> grab a brush and paint.
>
> =E2=80=94 Rob

Hi Rob.

First of all, I'm very much in favor of type aliases generally, so thank=
 you for taking a swing at this.

Second, it looks like you've run into the main design issue that has alw=
ays prevented them in the past: Should aliases be file-local and thus no=
t reusable, or global and thus we need to figure out autoloading for the=
m?  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 synt=
actically.

There seems to be two different implementations living in the same RFC, =
uncomfortably.  In one, it's a compiler-time replacement.  In the other,=
 it's a special class-like.  But the RFC seems to go back and forth on w=
hat happens in which case, and I'm not sure which is which.

However, you have demonstrated a working class-like for it, which is fra=
nkly the biggest hurdle.  So I think the direction has promise, but shou=
ld be adjusted to go all-in on that approach.

To wit:

typealias Stringy: string|Stringable;
typealias UserID: Int;
typealias TIme: Hour|Minute|Second;
typealias FilterCallback: callable(mixed $a): bool;  (eventually...)

(etc.)

Each of those produces a class-like, which can therefore be autoloaded l=
ike 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 reusab=
le thing (whereas "use" does not do that currently).  And the syntax is =
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 runtime=
, so reflection is meaningful.

Aliases can then be used only in parameter, return, property, and instan=
ceof types.  Extends and implements are out of scope entirely.

(Whether the keyword is typealias or typedef, uses : or =3D, or whatever=
, is its own bikeshed I won't dive into at the moment.)

Then, as a separate, entirely optional, maybe even separate RFC (or seco=
nd vote, or whatever), we have a `use string|Stringable as Stringy` synt=
ax.  Like all other `use` declarations, these are compile-time only, sin=
gle-file only, and do not exist at runtime, so no reflection.  They comp=
ile away just like all other use-statements now.

I'm not personally convinced the second is really necessary if we do a g=
ood enough job on the first, but I'd probably not stand in the way of ha=
ving both.

Having typealias/typedef as a class-like also opens up some interesting =
potential in the future, because classes have all sorts of other things =
they do, but that is probably too complex scope creepy to get into here =
so I will not go further than that mention.

I suspect there's also other edge case bits to worry about, particularly=
 if trying to combine a complex alias with a complex type, which could l=
ead to violating the DNF rule.  For example:

typealias Foo: (Bar&Baz)|Beep;

use (Bar&Baz)|Beep as Foo;

function narf(Foo&Stringable $s) {}

With the compile time approach, that would expand to `(Bar&Baz)|Beep&Str=
ingable`, which is not a valid type def.

With the runtime approach, I don't know if that could be handled gracefu=
lly or if it would still cause an error.

I'm not sure what the right solution is on this one, just pointing it ou=
t as a thing to resolve.

--Larry Garfield