Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130773
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 05 May 2026 10:48:54 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <c848b662-0bf3-4ace-aab8-8fdcb08501e2@app.fastmail.com>
In-Reply-To: 
 <CALaXqqSfgcEkYsQMRp9RU=z+n7Vi2Rp=rHxVZm9D7Hx3y7-DUQ@mail.gmail.com>
References: 
 <CALaXqqS+rGe3eELhmK684D1bdMdJdR9u4pJnT1ctZBzpgvnkaw@mail.gmail.com>
 <BA9E1314-ACFB-4AFC-8897-8EA3CF9B46E2@php.net>
 <CALaXqqRV29brJRYL_1dtSqyNq_V=EHPXVJO7XO7EQynPGJ_xAA@mail.gmail.com>
 <d87a2632-2f41-4d8e-a481-8e9a1c418109@app.fastmail.com>
 <CALaXqqSfgcEkYsQMRp9RU=z+n7Vi2Rp=rHxVZm9D7Hx3y7-DUQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add ReflectionAttribute::getCurrent()
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, May 4, 2026, at 4:58 PM, Daniel Scherzer wrote:
> On Mon, May 4, 2026 at 2:47=E2=80=AFPM Rob Landers <rob@bottled.codes>=
 wrote:
>> __
>>=20
>>=20
>> On Mon, May 4, 2026, at 23:22, Daniel Scherzer wrote:
>>>=20
>>> On Mon, May 4, 2026 at 2:13=E2=80=AFPM Derick Rethans <derick@php.ne=
t> wrote:
>>>> On 4 May 2026 21:24:39 BST, Daniel Scherzer <daniel.e.scherzer@gmai=
l.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 reflectio=
n target
>>>> >of an attribute.
>>>> >
>>>> >* RFC: https://wiki.php.net/rfc/reflectionattribute-getcurrent
>>>>=20
>>>>=20
>>>> "a new static method, ReflectionAttribute::getCurrent(), that, when=
 called from an attribute constructor, returns a reflection object corre=
sponding to what the attribute was applied to."
>>>>=20
>>>> 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 c=
all.
>>>>=20
>>>> I believe it's useful to have something like this, but I'm not in f=
avour of this approach.
>>>>=20
>>>> Would it not be possible for this to be a normal (dynamic) method o=
n the ReflectionAttrbute object?
>>>>=20
>>>> cheers
>>>> Derick
>>>=20
>>> I agree that this is a bit odd, but the problem with just adding a d=
ynamic method on the ReflectionAttribute object is that, in the attribut=
e constructor, there is no access to the ReflectionAttribute instance (u=
nless you want to extract it from the backtrace, which we shouldn't sugg=
est). Internally, the implementation is doing that backtrace processing =
in a more stable way than userland probably would.
>>>=20
>>> We could adjust the signature, so that there is still a static metho=
d to *get* the ReflectionAttribute, but then a normal dynamic method cal=
l on that object to get the target reflection object:
>>>=20
>>> ```
>>> class ReflectionAttribute {
>>>=20
>>>     // Call from the constructor of an attribute to get the original=
 ReflectionAttribute instance
>>>     public static function getCurrent(): ReflectionAttribute {}
>>>=20
>>>     // After using getCurrent(), use this to get the reflection targ=
et
>>>     public function getReflectionTarget(): ReflectionAttributeTarget=
 {}
>>> }
>>> ```
>>>=20
>>> but either way I think we need some kind of (C-implemented) backtrac=
e 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 a=
n arbitrary depth.
>>>=20
>>> An alternative would be to provide the reflection target (or the Ref=
lectionAttribute instance) to the attribute constructor as a parameter, =
but then we need some kind of way for attribute classes to signal that t=
hey 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 int=
erface, even though constructors are exempt from signature checks?) that=
 would probably make that harder to reason with for end users.
>>>=20
>>> -Daniel=20
>>=20
>> What about simply allowing an acceptance of the ReflectionAttribute i=
n the constructor? Engine-level injection, basically. You could have it =
transparent from the attribute (kinda like self from python):
>>=20
>> #[Attribute]
>> class Att {
>>   public function __construct(RelectionAttributeTarget $self, string =
$name) {}
>> }
>>=20
>> function thing(#[Att("name")] string $b) {}
>>=20
>> It'd still be something "special" but attributes are already kinda sp=
ecial and magical.
>>=20
>> =E2=80=94 Rob
>
>
> The problem with the lack of an explicit opt-in is that it would break=20
> existing attributes E.g. on 8.5, ReflectionAttribute::newInstance() fo=
r=20
> that example `Att` would be called with a single argument (the string)=
,=20
> and on 8.6 it would be called with 2 arguments (the=20
> ReflectionAttributeTarget and the string) without the attribute author=20
> having, *or attribute user*, having changed anything.
>
> And you might think we could check based on parameter types, but then=20
> the attribute would be dropping support for older versions of PHP,=20
> whereas with a "magic" method the call could be conditional.
>
> Plus, just because a class *can* be used as an attribute, does not mea=
n=20
> it *must always* be used as an attribute - and I found at least one=20
> case in symfony tests where they actually manually instantiate an=20
> attribute,=20
> https://github.com/symfony/symfony/blob/8e8f87c6fa5f47a431fc2f49bdbe60=
1f6769e19d/src/Symfony/Component/JsonPath/Tests/Attribute/AsJsonPathFunc=
tionTest.php.
>
> Basically, if we provided the reflection information (whether it is a=20
> ReflectionAttribute or ReflectionAttributeTarget) via a parameter, we=20
> would run into one or more of the following
>
> * without any opt-in, breaking existing attributes by adding a new=20
> unexpected parameter
> * with an implicit opt-in of a typed parameter, breaking backwards=20
> compatibility for attributes supporting multiple versions of PHP
> * with an explicit opt-in of *this parameter should have the reflectio=
n=20
> information*, similar backwards compatibility breaks
> * confusion for library authors about how to use the new feature
>
> I agree that this is a bit weird as a calling pattern, but I've been=20
> trying to think of an alternative for months (I first started working=20
> on this at Longhorn PHP in October) and haven't been able to come up=20
> with anything cleaner.
>
> The only slight improvement I had thought of a few months ago was the=20
> addition of the instance method on ReflectionAttribute to get the=20
> reflection target, and then separately ::getCurrent() would return the=20
> ReflectionAttribute instance, but I think some "magic" method like thi=
s=20
> is still needed.
>
> -Daniel

For context, there was a discussion last year about this problem space:

https://externals.io/message/127853

The issue is that there's really no good, clean solution to giving an at=
tribute access to the reflection target it is on.  All options have some=
 significant drawback.  (See that thread for details.)

I don't like it either, but this approach is the least-bad I can think o=
f.  If someone has a better alternative with fewer trade-offs, do share.

I believe this would let me greatly simplify AttributeUtils, in practice.

(Disclosure: Daniel and I discussed this issue at length back at Longhor=
n PHP, along with a few others.)

--Larry Garfield