Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130769
Precedence: list
MIME-Version: 1.0
References: <CALaXqqS+rGe3eELhmK684D1bdMdJdR9u4pJnT1ctZBzpgvnkaw@mail.gmail.com>
 <BA9E1314-ACFB-4AFC-8897-8EA3CF9B46E2@php.net>
In-Reply-To: <BA9E1314-ACFB-4AFC-8897-8EA3CF9B46E2@php.net>
Date: Mon, 4 May 2026 14:22:48 -0700
Message-ID: <CALaXqqRV29brJRYL_1dtSqyNq_V=EHPXVJO7XO7EQynPGJ_xAA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add ReflectionAttribute::getCurrent()
To: Derick Rethans <derick@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000005851a20651048a7b"
From: daniel.e.scherzer@gmail.com (Daniel Scherzer)

--0000000000005851a20651048a7b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 4, 2026 at 2:13=E2=80=AFPM Derick Rethans <derick@php.net> wrot=
e:

> 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 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

--0000000000005851a20651048a7b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote gmail=
_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 4, 2026=
 at 2:13=E2=80=AFPM Derick Rethans &lt;<a href=3D"mailto:derick@php.net">de=
rick@php.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">On 4 May 2026 21:24:39 BST, Daniel Scherzer &lt;<a href=3D"mail=
to:daniel.e.scherzer@gmail.com" target=3D"_blank">daniel.e.scherzer@gmail.c=
om</a>&gt; wrote:<br>
&gt;Hi internals,<br>
&gt;<br>
&gt;I&#39;d like to start the discussion for a new RFC about adding a new m=
ethod,<br>
&gt;ReflectionAttribute::getCurrent(), to access the current reflection tar=
get<br>
&gt;of an attribute.<br>
&gt;<br>
&gt;* RFC: <a href=3D"https://wiki.php.net/rfc/reflectionattribute-getcurre=
nt" rel=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/reflectio=
nattribute-getcurrent</a><br>
<br>
<br>
&quot;a new static method, ReflectionAttribute::getCurrent(), that, when ca=
lled from an attribute constructor, returns a reflection object correspondi=
ng to what the attribute was applied to.&quot;<br>
<br>
This sounds like an arbitrary new rule for just this functionality. I don&#=
39;t think we should have special rules for a single static method call.<br=
>
<br>
I believe it&#39;s useful to have something like this, but I&#39;m not in f=
avour of this approach.<br>
<br>
Would it not be possible for this to be a normal (dynamic) method on the Re=
flectionAttrbute object?<br>
<br>
cheers<br>
Derick</blockquote><div><br></div><div>I agree that this is a bit odd, but =
the problem with just adding a dynamic method on the ReflectionAttribute ob=
ject is that, in the attribute constructor, there is no access to the Refle=
ctionAttribute instance (unless you want to extract it from the backtrace, =
which we shouldn&#39;t suggest). Internally, the implementation is doing th=
at backtrace processing in a more stable way than userland probably would.<=
/div><div><br></div><div>We could adjust the signature, so that there is st=
ill a static method to *get* the ReflectionAttribute, but then a normal dyn=
amic method call on that object to get the target reflection object:</div><=
div><br></div><div>```</div><div>class ReflectionAttribute {</div><div><br>=
</div><div>=C2=A0 =C2=A0 // Call from the constructor of an attribute to ge=
t the original ReflectionAttribute instance</div><div>=C2=A0 =C2=A0 public =
static function getCurrent(): ReflectionAttribute {}</div><div><br></div><d=
iv>=C2=A0 =C2=A0 // After using getCurrent(), use this to get the reflectio=
n target</div><div>=C2=A0 =C2=A0 public function getReflectionTarget():=C2=
=A0ReflectionAttributeTarget {}</div><div>}</div><div>```</div><div><br></d=
iv><div>but either way I think we need some kind of (C-implemented) backtra=
ce processing, and because of that it makes sense to limit this to *just* a=
ttribute 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 provi=
de the reflection target (or the ReflectionAttribute instance) to the attri=
bute constructor as a parameter, but then we need some kind of way for attr=
ibute 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 differe=
nt attribute? add an interface, even though constructors are exempt from si=
gnature checks?) that would probably make that harder to reason with for en=
d users.</div><div><br></div><div>-Daniel=C2=A0</div></div></div>

--0000000000005851a20651048a7b--