On Fri, Sep 6, 2024, at 22:45, Larry Garfield wrote:
> 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 always 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 them? 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 syntactically.
>
> 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 what happens in which case, and I'm not sure which is which.
>
> However, you have demonstrated a working class-like for it, which is frankly the biggest
> hurdle. So I think the direction has promise, but should 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 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 reusable 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 instanceof types. Extends
> and implements are out of scope entirely.
>
> (Whether the keyword is typealias or typedef, uses : or =, 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 second vote, or whatever),
> we have a use string|Stringable as Stringy syntax. Like all other use
> declarations, these are compile-time only, single-file only, and do not exist at runtime, so no
> reflection. They compile away just like all other use-statements now.
>
> 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 and complexity.
>
> 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 lead to violating the DNF rule. For
> example:
Oh, DNF is the bane of my existence with this RFC—I don't want to mess this up. I'll see
you at the end of the example, though.
>
> 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&Stringable, which is not a valid type def.
I can see how you arrived at this, but I think you may have missed a step, since the entirety of Foo
will be &'d with Stringable.
Foo = (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 compiles—https://3v4l.org/0bMlP):
(Beep & Stringable) | (Bar & Baz & Stringable)
It's probably a good idea to update the RFC explaining how expansion works.
>
> With the runtime approach, I don't know if that could be handled gracefully or if it would
> still cause an error.
>
> I'm not sure what the right solution is on this one, just pointing it out as a thing to
> resolve.
>
> --Larry Garfield
>
— Rob