pon., 11 mar 2024 o 15:30 Larry Garfield <la...@garfieldtech.com> napisał(a):
> On Mon, Mar 11, 2024, at 8:35 AM, Michał Marcin Brzuchalski wrote: > > Hi Larry, > > > > pt., 8 mar 2024 o 16:55 Larry Garfield <la...@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(). 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. Cheers, Michał Marcin Brzuchalski
