On Tue, May 12, 2026 at 1:37 PM Benjamin Außenhofer <[email protected]> wrote:
> > > Am 04.05.2026, 22:24:39 schrieb Daniel Scherzer < > [email protected]>: > >> Hi internals, >> >> I'd like to start the discussion for a new RFC about adding a new method, >> ReflectionAttribute::getCurrent(), to access the current reflection target >> of an attribute. >> >> * RFC: https://wiki.php.net/rfc/reflectionattribute-getcurrent >> * Implementation: https://github.com/php/php-src/pull/21440 >> >> Thanks, >> -Daniel >> > > Hi Daniel, > > I am not convinced this is needed. At every call site of > $reflector->getAttributes() you could inject the reflector back into the > attributes. > > $attributes = $reflector->getAttributes(); > foreach ($attributes as $attribute) { > $instance = $attribute->newInstance(); > $instance->setReflector($reflector); > } > This would mean that * some initialization is deferred from the attribute constructor to its `setReflector()` method * callers that fail to use `setReflector()` will be misusing the attribute, all callers need to call `setReflector()` to properly use the attribute * the internal details of the attribute (e.g. the fact that it cares about what it is applied to) get exposed by the presence of the method > > If you have a framework, or library, handling attributes, you could > introduce an interface: ReflectionAwareAttribute with setReflector() to > generalize this: > > foreach ($attributes as $attribute) { > $instance = $attribute->newInstance(); > if ($instance instanceof ReflectionAwareAttribute) { > $instance->setReflector($reflector); > } > } > > The „magic" of this method knowing its context reminds me of internal > functions that were en voque in PHP 3/4 times, but for example > get.class(null) is not allowed anymore, func_get_args() is now superseded > by …$args and so on. > > IFF we decide this is helpful, could we think about doing this with > interface injection like the code above or AttributeUtils? > > greetings > Benjamin > This RFC was in part motivated by simplifying AttributeUtils and allowing the language to handle some of the functionality. This kind of calling of setter methods is exactly what AttributeUtils does now. Are you suggesting that the behavior of using a setReflector() method and opting in via interfaces is what the language should do automatically when calling ReflectionAttribute::newInstance()? That would still lead to the weird partial initialization between the constructor and setReflector() calls, and while it might not be an issue for attributes created from ReflectionAttribute, it would be a footgun if attributes are manually instantiated but are expecting to have setReflector() called on them immediately. If you haven't already, I suggest checking out the thread that Larry linked to in a prior reply - https://externals.io/message/127853 has a lot of discussion of drawbacks and trade-offs. I fully agree with Larry's conclusion in https://news-web.php.net/php.internals/130773 earlier in this discussion. -Daniel
