Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130772
Precedence: list
MIME-Version: 1.0
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>
In-Reply-To: <d87a2632-2f41-4d8e-a481-8e9a1c418109@app.fastmail.com>
Date: Mon, 4 May 2026 14:58:52 -0700
Message-ID: <CALaXqqSfgcEkYsQMRp9RU=z+n7Vi2Rp=rHxVZm9D7Hx3y7-DUQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add ReflectionAttribute::getCurrent()
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000047d32c0651050b82"
From: daniel.e.scherzer@gmail.com (Daniel Scherzer)

--00000000000047d32c0651050b82
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 4, 2026 at 2:47=E2=80=AFPM Rob Landers <rob@bottled.codes> wrot=
e:

>
>
> On Mon, May 4, 2026, at 23:22, Daniel Scherzer wrote:
>
>
> On Mon, May 4, 2026 at 2:13=E2=80=AFPM Derick Rethans <derick@php.net> wr=
ote:
>
> 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 targ=
et
> >of an attribute.
> >
> >* RFC: https://wiki.php.net/rfc/reflectionattribute-getcurrent
>
>
> "a new static method, ReflectionAttribute::getCurrent(), that, when calle=
d
> 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 dynami=
c
> method on the ReflectionAttribute object is that, in the attribute
> constructor, there is no access to the ReflectionAttribute instance (unle=
ss
> you want to extract it from the backtrace, which we shouldn't suggest).
> Internally, the implementation is doing that backtrace processing in a mo=
re
> 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 th=
ey
> want to be given that parameter, and then you get into the weeds on how t=
o
> 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 th=
e
> 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 $nam=
e) {}
> }
>
>
> function thing(#[Att("name")] string $b) {}
>
>
> It'd still be something "special" but attributes are already kinda specia=
l
> and magical.
>
> =E2=80=94 Rob
>


The problem with the lack of an explicit opt-in is that it would break
existing attributes E.g. on 8.5, ReflectionAttribute::newInstance() for
that example `Att` would be called with a single argument (the string), and
on 8.6 it would be called with 2 arguments (the ReflectionAttributeTarget
and the string) without the attribute author having, *or attribute user*,
having changed anything.

And you might think we could check based on parameter types, but then the
attribute would be dropping support for older versions of PHP, whereas with
a "magic" method the call could be conditional.

Plus, just because a class *can* be used as an attribute, does not mean it
*must always* be used as an attribute - and I found at least one case in
symfony tests where they actually manually instantiate an attribute,
https://github.com/symfony/symfony/blob/8e8f87c6fa5f47a431fc2f49bdbe601f676=
9e19d/src/Symfony/Component/JsonPath/Tests/Attribute/AsJsonPathFunctionTest=
.php
.

Basically, if we provided the reflection information (whether it is a
ReflectionAttribute or ReflectionAttributeTarget) via a parameter, we would
run into one or more of the following

* without any opt-in, breaking existing attributes by adding a new
unexpected parameter
* with an implicit opt-in of a typed parameter, breaking backwards
compatibility for attributes supporting multiple versions of PHP
* with an explicit opt-in of *this parameter should have the reflection
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 trying
to think of an alternative for months (I first started working on this at
Longhorn PHP in October) and haven't been able to come up with anything
cleaner.

The only slight improvement I had thought of a few months ago was the
addition of the instance method on ReflectionAttribute to get the
reflection target, and then separately ::getCurrent() would return the
ReflectionAttribute instance, but I think some "magic" method like this is
still needed.

-Daniel

--00000000000047d32c0651050b82
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, May 4, 2026 at 2:47=E2=80=AFPM Ro=
b Landers &lt;rob@bottled.codes&gt; wrote:</div><div class=3D"gmail_quote g=
mail_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u>=
</u><div><div><br></div><div><br></div><div>On Mon, May 4, 2026, at 23:22, =
Daniel Scherzer wrote:</div><blockquote type=3D"cite" id=3D"m_-281517557354=
6955935qt"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><div><div dir=3D"ltr=
">On Mon, May 4, 2026 at 2:13=E2=80=AFPM Derick Rethans &lt;<a href=3D"mail=
to:derick@php.net" target=3D"_blank">derick@php.net</a>&gt; wrote:</div><bl=
ockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div>On 4 May 2026 21:24:39 BST, Daniel Scherzer &=
lt;<a href=3D"mailto:daniel.e.scherzer@gmail.com" target=3D"_blank">daniel.=
e.scherzer@gmail.com</a>&gt; wrote:</div><div> &gt;Hi internals,</div><div>=
 &gt;</div><div> &gt;I&#39;d like to start the discussion for a new RFC abo=
ut adding a new method,</div><div> &gt;ReflectionAttribute::getCurrent(), t=
o access the current reflection target</div><div> &gt;of an attribute.</div=
><div> &gt;</div><div> &gt;* RFC: <a href=3D"https://wiki.php.net/rfc/refle=
ctionattribute-getcurrent" rel=3D"noreferrer" target=3D"_blank">https://wik=
i.php.net/rfc/reflectionattribute-getcurrent</a></div><div> <br></div><div>=
 <br></div><div> &quot;a new static method, ReflectionAttribute::getCurrent=
(), that, when called from an attribute constructor, returns a reflection o=
bject corresponding to what the attribute was applied to.&quot;</div><div> =
<br></div><div> This sounds like an arbitrary new rule for just this functi=
onality. I don&#39;t think we should have special rules for a single static=
 method call.</div><div> <br></div><div> I believe it&#39;s useful to have =
something like this, but I&#39;m not in favour of this approach.</div><div>=
 <br></div><div> Would it not be possible for this to be a normal (dynamic)=
 method on the ReflectionAttrbute object?</div><div> <br></div><div> cheers=
</div><div> Derick</div></blockquote><div><br></div><div>I agree that this =
is a bit odd, but the problem with just adding a dynamic method on the Refl=
ectionAttribute object is that, in the attribute constructor, there is no a=
ccess to the ReflectionAttribute instance (unless you want to extract it fr=
om the backtrace, which we shouldn&#39;t suggest). Internally, the implemen=
tation is doing that backtrace processing in a more stable way than userlan=
d probably would.</div><div><br></div><div>We could adjust the signature, s=
o 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 reflect=
ion object:</div><div><br></div><div>```</div><div>class ReflectionAttribut=
e {</div><div><br></div><div>=C2=A0 =C2=A0 // Call from the constructor of =
an attribute to get the original ReflectionAttribute instance</div><div>=C2=
=A0 =C2=A0 public static function getCurrent(): ReflectionAttribute {}</div=
><div><br></div><div>=C2=A0 =C2=A0 // After using getCurrent(), use this to=
 get the reflection target</div><div>=C2=A0 =C2=A0 public function getRefle=
ctionTarget():=C2=A0ReflectionAttributeTarget {}</div><div>}</div><div>```<=
/div><div><br></div><div>but either way I think we need some kind of (C-imp=
lemented) backtrace processing, and because of that it makes sense to limit=
 this to *just* attribute constructors so that we don&#39;t need to process=
 backtraces to an arbitrary depth.</div><div><br></div><div>An alternative =
would be to provide the reflection target (or the ReflectionAttribute insta=
nce) to the attribute constructor as a parameter, but then we need some kin=
d of way for attribute classes to signal that they want to be given that pa=
rameter, and then you get into the weeds on how to opt-in (mark the paramet=
er with a different attribute? add an interface, even though constructors a=
re exempt from signature checks?) that would probably make that harder to r=
eason with for end users.</div><div><br></div><div>-Daniel=C2=A0</div></div=
></div></blockquote><div><br></div><div>What about simply allowing an accep=
tance of the ReflectionAttribute in the constructor? Engine-level injection=
, basically. You could have it transparent from the attribute (kinda like s=
elf from python):</div><div><br></div><pre style=3D"border-width:1px;border=
-style:solid;border-color:rgb(204,204,204);border-radius:3px;background-ima=
ge:initial;background-size:initial;background-repeat:initial;background-ori=
gin:initial;background-clip:initial;background-color:rgb(246,246,246);font-=
family:menlo,consolas,monospace;font-size:90%;margin:7px 0px;padding:7px 10=
px">#[Attribute]
class Att {
  public function __construct(RelectionAttributeTarget $self, string $name)=
 {}
}</pre><div><br></div><pre style=3D"border-width:1px;border-style:solid;bor=
der-color:rgb(204,204,204);border-radius:3px;background-image:initial;backg=
round-size:initial;background-repeat:initial;background-origin:initial;back=
ground-clip:initial;background-color:rgb(246,246,246);font-family:menlo,con=
solas,monospace;font-size:90%;margin:7px 0px;padding:7px 10px">function thi=
ng(#[Att(&quot;name&quot;)] string $b) {}</pre><div><br></div><div>It&#39;d=
 still be something &quot;special&quot; but attributes are already kinda sp=
ecial and magical.</div><div><br></div><div id=3D"m_-2815175573546955935sig=
121229152">=E2=80=94 Rob</div></div></blockquote><div><br></div><div><br></=
div><div>The problem with the lack of an explicit opt-in is that it would b=
reak existing attributes E.g. on 8.5, ReflectionAttribute::newInstance() fo=
r that example `Att` would be called with a single argument (the string), a=
nd on 8.6 it would be called with 2 arguments (the ReflectionAttributeTarge=
t and the string) without the attribute author having, *or attribute user*,=
 having changed anything.</div><div><br></div><div>And you might think we c=
ould check based on parameter types, but then the attribute would be droppi=
ng support for older versions of PHP, whereas with a &quot;magic&quot; meth=
od the call could be conditional.</div><div><br></div><div>Plus, just becau=
se a class *can* be used as an attribute, does not mean it *must always* be=
 used as an attribute - and I found at least one case in symfony tests wher=
e they actually manually instantiate an attribute,=C2=A0<a href=3D"https://=
github.com/symfony/symfony/blob/8e8f87c6fa5f47a431fc2f49bdbe601f6769e19d/sr=
c/Symfony/Component/JsonPath/Tests/Attribute/AsJsonPathFunctionTest.php">ht=
tps://github.com/symfony/symfony/blob/8e8f87c6fa5f47a431fc2f49bdbe601f6769e=
19d/src/Symfony/Component/JsonPath/Tests/Attribute/AsJsonPathFunctionTest.p=
hp</a>.</div><div><br></div><div>Basically, if we provided the reflection i=
nformation (whether it is a ReflectionAttribute or ReflectionAttributeTarge=
t) via a parameter, we would run into one or more of the following</div><di=
v><br></div><div>* without any opt-in, breaking existing attributes by addi=
ng a new unexpected parameter</div><div>* with an implicit opt-in of a type=
d parameter, breaking backwards compatibility for attributes supporting mul=
tiple versions of PHP</div><div>* with an explicit opt-in of *this paramete=
r should have the reflection information*, similar backwards compatibility =
breaks</div><div>* confusion for library authors about how to use the new f=
eature</div><div><br></div><div>I agree that this is a bit weird as a calli=
ng pattern, but I&#39;ve been trying to think of an alternative for months =
(I first started working on this at Longhorn PHP in October) and haven&#39;=
t been able to come up with anything cleaner.</div><div><br></div><div>The =
only slight improvement I had thought of a few months ago was the addition =
of the instance method on ReflectionAttribute to get the reflection target,=
 and then separately ::getCurrent() would return the ReflectionAttribute in=
stance, but I think some &quot;magic&quot; method like this is still needed=
.</div><div><br></div><div>-Daniel=C2=A0</div></div></div>

--00000000000047d32c0651050b82--