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
