On Sat, Sep 7, 2024, at 14:42, Mike Schinkel wrote:
> > On Sep 6, 2024, at 4:45 PM, Larry Garfield <[email protected]> wrote:
> > Aliases can then be used only in parameter, return, property, and instanceof types.
> > Extends and implements are out of scope entirely.
>
> Is there a strong technical reason why extends and implements should be out of scope?
>
> 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.
>
> > On Sep 6, 2024, at 8:46 PM, Davey Shafik <[email protected]> wrote:
> > I would very much prefer to either go all in with an Enum-like (which means that we can
> > hang methods on to the value) or we need to distinguish between type hints for class-likes and type
> > hints for not-class-likes (*Bar anyone?).
>
> Allowing methods also have definite value as most use-cases I have seen in other languages
> alias in order to add methods, especially for enabling support of interfaces.
>
> Which, however, brings up an important distinction that other languages have made and which I
> think PHP would benefit from addressing:
>
> 1. Type Alias => Different Name for Same Type
> 2. Type Def => New Type which has all the same properties and methods of other type
>
> e.g. (being hypothetical with the syntax; bikeshed away):
>
> typealias LocalWidget: Widget
>
> typedef MyWidget: Widget {
> function foo() {...}
> }
>
> function doSomething(Widget $widget) {...}
>
> $w = new LocalWidget;
> doSomething($w); // This works, no problem as LocalWidget === Widget
>
> $w = new MyWidget;
> doSomething($w); // This throws an error as MyWidget !== Widget
>
> -Mike
>
>
Hey Mike,
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.
I feel like any aliasing for primitive/intersection/union types should feel like an extension of
that for local aliases. For 'project-wide' aliases, I'm open to much more different
syntax, like typealias or even 'alias'.
As far as extends/implements go, I plan to keep it the same for simple class aliases as there is
utility there and the RFC already covers this.
— Rob