Re: bikeshed: Typed Aliases

On Sat, Sep 7, 2024, at 14:42, Mike Schinkel wrote: > > On Sep 6, 2024, at 4:45 PM, Larry Garfield <larry@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 <davey@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