On Mon, Mar 11, 2024, at 4:58 PM, Michał Marcin Brzuchalski wrote:
>> 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().
>
> It is similar when you work with ReflectionType or ReflectionEnum, you
> always need to match against a certain type to ensure the code will
> behave predictably.
>
>> $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?
>
> My thinking was like:
> 1. if the property has hooks, only then calling getRawValue,
> setRawValue, or isVirtual make sense,
> 2. if the property has no hooks and is static calling getRawValue, or
> setRawValue always throws because of "On a static property, this method
> will always throw an error."
> 3. if the property is "virtual", calling getRawValue, or setRawValue
> always throws an error,
> 4. if the property is not "virtual", calling getValue, or setValue is
> safe and never throws, otherwise it may throw under some conditions
> related to certain hook presence.
>
> In conclusion, I thought that the presence of hooks introduces 3 new
> methods but some will always be thrown because of incorrect usage.
> Normally, I'd model it with subtypes to completely avoid try-catch
> blocks for the cost of a simple instanceof check which I consider much
> cleaner for the reader than a bunch of try-catch blocks. Remember about
> static analysis, each of them when checked will propose to handle
> possible exceptions.
>
> But as wrote before, I don't know how to model it well.
Agreed, though I don't know how to model it either. :-) If someone can figure
out a way to do so before we go to a vote, we'll consider it.
--Larry Garfield
