Re: bikeshed: Typed Aliases

> On Sep 7, 2024, at 9:28 AM, Rob Landers <rob@bottled.codes> wrote: > Keep in mind there is already single-class aliasing with well-known behavior for both local and > project-wide aliases. Local aliases are done through 'use' statements, and project-wide > aliases can be created by using the class_alias() function. Good point. While I'd prefer to be able to use a typedef/typealias syntax, I certainly would not bikeshed over it. > On Sep 7, 2024, at 9:21 AM, Larry Garfield <larry@garfieldtech.com> wrote: >> There is definite utility for this, to create a local alias in a >> namespace that can be used throughout the namespace rather than having >> to refer to the external namespace in many different places. > > Because it quickly can produce nonsensical syntax. > > class A {} > class B {} > > typealias AB: A|B; > > // This is logically nonsensical. > class C extends AB {} Gotcha. That issue had not occurred to me as my use of type aliases is in other languages that do not have union types. So I was more concerned with this: namespace A\Really\Long\Namespace { class A {} } namespace My\Current\Namespace { typedef A: \A\Really\Long\Namespace\A {} class B extends A {} } However, as Rob pointed out there are already ways to accomplish this that I was not thinking of, so my concern for extends and implements is effectively moot. > On Sep 7, 2024, at 9:28 AM, Larry Garfield <larry@garfieldtech.com> wrote: > Methods on typedefs was the sort of "other stuff classes do" that I was trying to > avoid getting into right now. :-) Mainly because I can totally 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 talking type DEFs, not type ALIASes. That latter sentence is spot-on. -Mike