On Sat, Sep 7, 2024, at 14:42, Mike Schinkel wrote:
> > On Sep 6, 2024, at 4:45 PM, Larry Garfield <la...@garfieldtech.com> 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 <da...@php.net> 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
