Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127871
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 03 Jul 2025 16:43:36 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <926ca0e2-13f4-47fc-aec3-f7fa265cfdb5@app.fastmail.com>
In-Reply-To: 
 <CAB-BujaAXVp1OPs0XLtVix_NBLjWjyx=TRtbTAnWw-Rzg91UZg@mail.gmail.com>
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>
Subject: Re: [PHP-DEV] [RFC idea] Target-aware attributes
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

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 values,
> which are then replaced in that separate method.
> (I call that a "setter", but only because it behaves like one from the
> 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 ran into the "completeness problem" in AttributeUtils as well.  In my case, it's not just reflection; there's a whole bunch of other things that can be passed back to the attribute to give it more context.  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 do better.)

Basically, any time you have multi-step construction you will have a period where the state is potentially incomplete.  While passing the reflection target in is one such multi-step case, there are lots of others, so in advanced cases (most of what I do) the object will always have an incomplete phase, and that's unavoidable.  So I'm not *that* worried about there being a brief incomplete-gap in time in core, because I'll always have one anyway, and I've already figured out how to handle it.

--Larry Garfield