Re: bikeshed: Typed Aliases

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