On Mon, May 4, 2026, at 23:22, Daniel Scherzer wrote:
>
> 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
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
