Re: [RFC[ Property accessor hooks, take 2
| From: | Larry Garfield | Date: | Mon, 11 Mar 2024 14:27:34 +0000 |
| Subject: | Re: [RFC[ Property accessor hooks, take 2 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-122610@lists.php.net to get a copy of this message | ||
On Mon, Mar 11, 2024, at 8:35 AM, Michał Marcin Brzuchalski wrote:
> Hi Larry,
>
> pt., 8 mar 2024 o 16:55 Larry Garfield <larry@garfieldtech.com> napisał(a):
>> Hi folks. Based on earlier discussions, we've made a number of changes to the RFC
>> that should address some of the concerns people raised. We also had some very fruitful discussions
>> off-list with several developers from the Foundation, which led to what we feel are some solid
>> improvements.
>>
>> https://wiki.php.net/rfc/property-hooks
>>
>
> This RFC looks awesome, thanks Larry and Ilija I love the functionality
> in its current shape.
>
>> Thank you everyone for the feedback so far, and if you still have some, please say so.
>> (Even if it's just to say that you're happy with the RFC now so we feel more comfortable
>> bringing it to a vote.)
>
> The only thing I don't like and can still be worked on is the
> reflection mechanism changes.
> The proposed methods isVirtual and getRawValue, setRawValue pair
> introduces a need to catch exceptions which could be eliminated by
> subtyping ReflectionProperty.
> Having these methods on a separate subtype allows returning a valid
> value.
> I realize this isn't trivial because for the last 2 days, I was
> thinking about giving it a name and TBH cannot figure out anything
> feasible.
> If this is not possible to put in understandable words then at least
> mention it in FAQ and why not.
>
> Cheers,
> Michał Marcin Brzuchalski
Hm, interesting. I'll have to check with Ilija on feasibility. My question is, how would it
eliminate it?
Suppose we hypothetically have a "ReflectionPropertyWithHooks" reflection object. It has
those three extra methods on it. But that means $rObject->getProperty() could return a
ReflectionProperty or ReflectionPropertyWithHooks, and you don't know which it is. You'd
have to do an instanceof check to know which type of property it is, and thus what methods are
available. That doesn't seem any less clumsy (nor more, to be fair) than calling isVirtual().
$rProp = $rObject->getProperty('foo', $obj);
$rProp->getValue(); // works always.
if (!$rProp->isVirtual()) {
$rProp->getRawValue(); // Works, may or may not be the same return as getValue()
}
vs.
if (!$rProp instanceof VirtualProperty) {
$rProp->getRawValue(); // Works.
}
That doesn't seem to be an improvement. If you omit the conditional, you still need a catch
one way or the other. It just changes what gets thrown (an Exception vs an Error). What type of
hierarchy were you thinking of that would help here?
--Larry Garfield