Re: [RFC[ Property accessor hooks, take 2

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