On Mon, May 4, 2026 at 2:13 PM Derick Rethans <[email protected]> wrote:
> On 4 May 2026 21:24:39 BST, Daniel Scherzer <[email protected]> > 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
