Re: [Vote] New in initializers
| From: | Nicolas Grekas | Date: | Tue, 06 Jul 2021 12:30:22 +0000 |
| Subject: | Re: [Vote] New in initializers | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-115320@lists.php.net to get a copy of this message | ||
> > > This is not 100% correct, you can have an attribte #[Foo(Foo::class)]
> and
> > > then calling ReflectionAttribute::getArguments would also require to
> > > resolve the type Foo. So this is not different than what could happen
> > right
> > > now already.
> >
> >
> > Despite its name, "::class" doesn't care about class definitions, it
> > just performs a string substitution based on the "namespace" and "use"
> > statements in the current file.
> >
> > In most cases, that happens entirely at compile time, so the following
> > two source files compile identically:
> >
>
> Hah, I realized after sending the example was bad :) I should have used an
> example using actual constants (vs magic ones):
>
> #[Foo(Foo::BAR)]
>
> This would trigger autoloading and resolving during getArguments()
>
Right!
Extending on my proposal, getUninitializedArguments() could return a
ReflectionConstant in place of such values.