Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127868
Precedence: bulk
MIME-Version: 1.0
References: <1cfc477a-781f-40e9-9e37-dd748ef261be@app.fastmail.com> <20DACB49-3C84-4B23-98E2-35050D9EDAC9@koalephant.com>
In-Reply-To: <20DACB49-3C84-4B23-98E2-35050D9EDAC9@koalephant.com>
Date: Thu, 3 Jul 2025 19:54:56 +0200
Message-ID: <CAB-BujY3vLBp7SVNXgUGC8_TWUKiCWnbyUJ7yXSjtK=yFdLGow@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC idea] Target-aware attributes
To: Stephen Reay <php-lists@koalephant.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: andreas@dqxtech.net (Andreas Hennings)

On Thu, 3 Jul 2025 at 19:17, Stephen Reay <php-lists@koalephant.com> wrote:
>
>
>
>
> Sent from my iPhone
> > On 3 Jul 2025, at 23:40, Larry Garfield <larry@garfieldtech.com> wrote:
> >
> > =EF=BB=BFOn Wed, Jul 2, 2025, at 5:26 PM, Andreas Hennings wrote:
> >> This topic was discussed in the past as "Declaration-aware
> >> attributes", and mentioned in the discussion to "Amendments to
> >> Attributes".
> >> I now want to propose a close-to-RFC iteration of this.
> >> (I don't have RFC Karma, my wiki account is "Andreas Hennings (donquix=
ote)")
> >>
> >> -----
> >>
> >> Primary proposal
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>
> >> I propose to introduce 3 new methods on ReflectionAttribute.
> >>
> >> static ReflectionAttribute::getCurrentTargetReflector(): ?Reflector
> >> Most of the time, this will return NULL.
> >> During the execution of ReflectionAttribute->newInstance(), it will
> >> return the reflector of the symbol on which the attribute is found.
> >> (in other words, during
> >> $reflector->getAttributes()[$i]->newInstance(), it will return
> >> $reflector.)
> >> During the execution of
> >> ReflectionAttribute::invokeWithTargetAttribute($target, $callback), it
> >> will return $target.
> >> If the call stack contains multiple calls to the above mentioned
> >> methods, only the closest/deepest one counts.
> >> (This means that php needs to maintain a stack of reflectors.)
> >
> > *snip*
> >
> >> Other alternatives
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>
> >> In older discussions, it was suggested to provide the target reflector
> >> as a special constructor parameter.
> >> This is problematic because an attribute expression #[MyAttribute('a',
> >> 'b', 'c')] expects to pass values to all the parameters.
> >>
> >> Another idea was to provide the target reflector through a kind of
> >> setter method on the attribute class.
> >> This can work, but it makes attribute classes harder to write, because
> >> the constructor does not have all the information.
> >> It may also prevent attribute classes from being stateless (depending
> >> how we define stateless).
> >>
> >>
> >> Userland implementations
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> >>
> >> One userland implementation that was mentioned in this list in the
> >> past is in the 'crell/attributeutils' package.
> >> This one uses a kind of setter injection for the target reflector.
> >> See
> >> https://github.com/Crell/AttributeUtils/blob/master/src/FromReflection=
Class.php
> >
> > Hey, I know that guy! :-)
> >
> >> Another userland implementation is in the
> >> 'ock/reflector-aware-attributes' package.
> >> https://github.com/ock-php/reflector-aware-attributes (I created that =
one)
> >> This supports both a setter method and getting the target reflector
> >> from the attribute constructor.
> >>
> >> The problem with any userland implementation is that it only works if
> >> the attribute is instantiated (or processed) using that userland
> >> library.
> >> Simply calling $reflector->getAttributes()[0]->newInstance() would
> >> either return an instance that is incomplete, or it would break, if
> >> the attribute class expects access to its target.
> >
> > I am unsurprisingly in favor of finding a solution here, as there are i=
nnumerable cases where you need the reflectable that the attribute is on; t=
he most common for me is using the name/type of a property as defaults for =
the attribute.
> >
> > However, I am very skeptical about a stateful global value as the solut=
ion.  We've tried very hard to remove those from PHP, mostly successfully. =
 Adding another one back in feels like a major step backwards, and a great =
place for weird bugs to hide.
> >
> > A setter method injection is what I did in AttributeUtils, because it w=
as the only real option.  Alternatively, I suppose core could use property =
setter injection (either a magically named property like $__reflector, or a=
 property that itself has an attribute on it, etc.).  That would allow it t=
o be set before the constructor is called, and with property hooks would al=
low processing either immediately or later in the constructor.  The downsid=
e here is that Attribute are, generally, serializable, but a Reflection obj=
ect is not.  So if someone wanted a serializable attribute they would have =
to accept the property, use it, and then remember to unset it at some point=
.  That's clumsy.
> >
> > --Larry Garfield
> >
>
> As someone that's written yet another userland "solution" for this proble=
m, I have an alternative solution, based somewhat on an internalised  conce=
pt of "never store Reflectors".
>
> Introduce an interface "ReflectorAttribute" (bike shedding to come); whic=
h accepts a single Reflector argument.
>
> If the attribute implements the interface, the method is called immediate=
ly following instantiation.

Yep, this is the "method injection" mentioned by Larry, or what I
referred to as "setter injection".
I have not seen your library, but I assume that's where it is going.

>
> Yes this means logic dependant on the reflector has to be delayed until t=
he method is called. I think this is an acceptable payoff for the solution:=
 it only applies to attributes that explicitly opt in to receive the Reflec=
tor, and it helps to not encourage storing the reflector in a property.

yep, same tradeoff I mentioned in the other mail.

>
> In theory I guess it could call a static named constructor, but the other=
 arguments would have to be an array, which would end up being quite clunky=
 if the goal is to derive default argument values from the reflector.
>
> I'm really looking forward to this feature, thanks for introducing this d=
iscussion/RFC!
>
>
>
> Cheers
>
> Stephen