> 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 <la...@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 <la...@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
