> On Sep 7, 2024, at 9:28 AM, Rob Landers <[email protected]> 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 <[email protected]> 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 <[email protected]> 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