Re: [RFC] Type Aliases

On Wed, Dec 3, 2025, at 22:27, Paul M. Jones wrote: > Hey Rob & all, > > One objection, one question. > > The objection is to include types 'types.php'. > You've clarified why types cannot be autoloaded (thanks again!) and so this is a way to let the > compiler know where the types are. But I have to say I've spent a huge part of my career > removing include/require when refactoring legacy code, and introducing it here causes me great > heartache. A new way of autoloading is out of scope... :D It doesn't preclude it from being autoloaded in the future, but currently, the only other reason to refactor autoloading would be to get function autoloading. That in itself would be nice, having another reason wouldn't necessarily be a bad thing either. Further up-thread, I mentioned there were two ways to do this: this way, and making aliases "global". For example, a "use global type ... as ..." or something like that. I'm not opposed to this, per se, and if that’s the consensus, I'm fine with it. > The question is a little more complicated, and also involves autoloading. Given a class Number > that can be autoloaded ... > > namespace Foo; > > class Number { /* ... */ } > > ... and *another* class in the same namespace, that creates a "number" type alias... > > namespace Foo; > > use type int|float as Number; > > class Bar { public function add(Number $a, Number $b) : Number { /* .... */ } > > ... which one "wins" -- the runtime autoloaded class, or the compile-time type alias? > > (Apologies if this is covered in the RFC and I missed it.) > It works just like it works today if you were to do this: namespace Foo { class Number {} } namespace Foo { use GMP as Number; class Bar { public function add Number $a, \Foo\Number $b): Number {} } In other words, the alias shadows the original and you have to use the FQN to resolve the real one. — Rob