Re: [RFC] [Discussion] Add ReflectionAttribute::getCurrent()

On Mon, May 4, 2026, at 23:22, Daniel Scherzer wrote: > > On Mon, May 4, 2026 at 2:13 PM Derick Rethans <derick@php.net> wrote: >> On 4 May 2026 21:24:39 BST, Daniel Scherzer <daniel.e.scherzer@gmail.com> wrote: >> >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 >> >> >> "a new static method, ReflectionAttribute::getCurrent(), that, when called from an >> attribute constructor, returns a reflection object corresponding to what the attribute was applied >> to." >> >> This sounds like an arbitrary new rule for just this functionality. I don't think we >> should have special rules for a single static method call. >> >> I believe it's useful to have something like this, but I'm not in favour of this >> approach. >> >> Would it not be possible for this to be a normal (dynamic) method on the ReflectionAttrbute >> object? >> >> cheers >> Derick > > I agree that this is a bit odd, but the problem with just adding a dynamic method on the > ReflectionAttribute object is that, in the attribute constructor, there is no access to the > ReflectionAttribute instance (unless you want to extract it from the backtrace, which we > shouldn't suggest). Internally, the implementation is doing that backtrace processing in a more > stable way than userland probably would. > > We could adjust the signature, so that there is still a static method to *get* the > ReflectionAttribute, but then a normal dynamic method call on that object to get the target > reflection object: > > ``` > class ReflectionAttribute { > > // Call from the constructor of an attribute to get the original ReflectionAttribute > instance > public static function getCurrent(): ReflectionAttribute {} > > // After using getCurrent(), use this to get the reflection target > public function getReflectionTarget(): ReflectionAttributeTarget {} > } > ``` > > but either way I think we need some kind of (C-implemented) backtrace processing, and because > of that it makes sense to limit this to *just* attribute constructors so that we don't need to > process backtraces to an arbitrary depth. > > An alternative would be to provide the reflection target (or the ReflectionAttribute instance) > to the attribute constructor as a parameter, but then we need some kind of way for attribute classes > to signal that they want to be given that parameter, and then you get into the weeds on how to > opt-in (mark the parameter with a different attribute? add an interface, even though constructors > are exempt from signature checks?) that would probably make that harder to reason with for end > users. > > -Daniel What about simply allowing an acceptance of the ReflectionAttribute in the constructor? Engine-level injection, basically. You could have it transparent from the attribute (kinda like self from python): #[Attribute] class Att { public function __construct(RelectionAttributeTarget $self, string $name) {} } function thing(#[Att("name")] string $b) {} It'd still be something "special" but attributes are already kinda special and magical. — Rob