Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127955
Precedence: bulk
MIME-Version: 1.0
References: <CAB-Buja3vt9ho3Hxf5FqFB-1vW7+11_2O3KpXdzFbiRBTviQVA@mail.gmail.com>
 <1cfc477a-781f-40e9-9e37-dd748ef261be@app.fastmail.com> <CAB-BujaAXVp1OPs0XLtVix_NBLjWjyx=TRtbTAnWw-Rzg91UZg@mail.gmail.com>
 <926ca0e2-13f4-47fc-aec3-f7fa265cfdb5@app.fastmail.com> <CAB-BujbJrvAmK+V49f9JUhR_g_XTrTBUtpB0QG6jeRyqh308Xg@mail.gmail.com>
 <c7f25b13-49fd-402a-80aa-f40342786f44@app.fastmail.com>
In-Reply-To: <c7f25b13-49fd-402a-80aa-f40342786f44@app.fastmail.com>
Date: Tue, 8 Jul 2025 01:54:37 +0200
Message-ID: <CAB-BujZ5_RZsrwKrA1rnftTULi+MwOReatZeNHzFYKvXZuQ05A@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC idea] Target-aware attributes
To: Larry Garfield <larry@garfieldtech.com>
Cc: 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 Mon, 7 Jul 2025 at 15:57, Larry Garfield <larry@garfieldtech.com> wrote:
>
> On Fri, Jul 4, 2025, at 6:50 PM, Andreas Hennings wrote:
> > On Thu, 3 Jul 2025 at 23:44, Larry Garfield <larry@garfieldtech.com> wr=
ote:
> >>
> >> On Thu, Jul 3, 2025, at 12:49 PM, Andreas Hennings wrote:
> >>
> >> >> A setter method injection is what I did in AttributeUtils, because =
it was the only real option.
> >> >
> >> > In my experience, this alternative leads to more complexity in
> >> > attribute classes.
> >> > The constructor needs to populate the attribute with temporary value=
s,
> >> > which are then replaced in that separate method.
> >> > (I call that a "setter", but only because it behaves like one from t=
he
> >> > outside, internally we usually don't want to store the reflector).
> >> >
> >> > Also, we can never be fully sure whether an attribute instance is
> >> > "complete" or not.
> >> > If the attribute instance is coming from
> >> > $reflection_attribute->newInstance(), we can be confident that the
> >> > ->injectReflector() or has been called.
> >> > But if the attribute was instantiated manually with "new ...", it
> >> > could as well be incomplete.
> >> > With ReflectionAttribute::getCurrentTargetReflector(), we can fail
> >> > early in the attribute constructor, by throwing on NULL.
> >>
> >
> > I somehow missed this reply earlier...
> >
> >> I ran into the "completeness problem" in AttributeUtils as well.  In m=
y case, it's not just reflection; there's a whole bunch of other things tha=
t can be passed back to the attribute to give it more context.
> >
> > There is a trade-off how much logic should live in the attribute vs
> > the code that parses the attribute.
> > In symfony DI there is a pattern where you register a callback for an
> > attribute class, which would allow to make the attribute agnostic of
> > the application or framework details.
> > E.g. you could have the same attribute for different DI systems.
> > (Perhaps this is not the reason why symfony does it in this way.)
> > On the other hand, keeping logic in the attribute class also has its be=
nefits.
> >
> > I did play around with dedicated interfaces for attributes per applicat=
ion.
> > I am not sure I like the overly generic interfaces I see in
> > AttributeUtils. But I would have to look deeper into it.
>
> Overly generic?  I don't follow.  The interfaces in AttributeUtils are al=
l, well, AttributeUtils interfaces.  You use them to opt-in to specific AU =
functionality. AU is framework agnostic, but the interface are naturally li=
brary-specific.

I may have be wrong on this one.
What I think to understand now is that your library allows e.g. your
class attribute to know about attributes on other symbols (e.g.
properties) in the same class.
This is ok, but other libraries might want to do these mechanics
outside of the attribute.

>
> >>  My eventual solution was to also have a `Finalizable` interface that =
is guaranteed to be the last thing called, so the attribute can handle any =
last-minute defaults.  I don't love it, but given the severe limitations of=
 `readonly` it was the best I could do.  (With aviz today, I could likely d=
o better.)
> >
> > The attribute object does not have to be your final "collectable".
> > You can have an attribute with a method that returns something else.
> > In fact I strongly prefer to _not_ pass attribute instances around
> > everywhere, because they often contain clutter that becomes useless
> > after the initial discovery.
>
> Possibly, but my experience with AU is that it's quite convenient to have=
 the attribute be the stored metadata.  The methods on the attributes are m=
ostly just to precompute some derived information (which could be a lot or =
a little).  The stored/cached object is only the size of its properties, so=
 as long as there's no set temporary properties there's no clutter to worry=
 about.
>
> >> Basically, any time you have multi-step construction you will have a p=
eriod where the state is potentially incomplete.
> >
> > It is not just about possible incompleteness, it is about being
> > deterministic as early as possible.
>
> It is always deterministic, as long as the order things happen is consist=
ent.
>
> > E.g. if two people enter a room, it could make _some_ things much
> > easier if you know whether they are brother and sister, or a married
> > couple.
>
> ... I have no earthly idea what you just said.

If you have a box with a cat in it, it can be useful to know whether
that cat is dead or alive, and the sooner you know it the better.
All I do here is advertise for having the target reflector available
in the constructor.

There is some bad taste of global state, but I don't see relevant
scenarios where it would manifest as something bad, with that proposed
self-clearing mechanism.

This said, I can easily imagine more than one solution to co-exist.
For many cases, the method injection will be just fine.

-- Andreas

>
> >> While passing the reflection target in is one such multi-step case, th=
ere are lots of others, so in advanced cases (most of what I do)...
> >
> > When looking at existing attributes in e.g. symfony or Drupal, or my
> > own experiments, I don't see the huge need to inject other things into
> > the attribute.
> > The reflector seems really the most commonly useful to me.
> >
> > E.g. an attribute on a method/function might have a parameter that is
> > optional or required depending on the method's return type.
> > Checking that in the constructor allows us to fail early, and makes
> > everything more deterministic.
>
> A key part of the design of AttributeUtils is that you always parse a cla=
ss; if there are attributes on a method in that class, they get parsed and =
then passed into the class attribute.  Similarly for properties, constants,=
 etc.  You can also have "sub attributes", which allow multiple attributes =
on the same target to be smushed together.  All of those involve passing th=
e attributes of the child-target to the parent-target's attribute.
>
> I agree, the reflector is the most critical and the part that would most =
benefit from help from the engine.  But there are other valid use cases for=
 multi-step build up.
>
> --Larry Garfield