Re: [RFC] Property hooks, nee accessors

> Regarding $field vs. $this->propName, there's a few reasons we went that route. > > 1. It's shorter and less typing for what will be a common pattern. > 2. That makes it consistent between hook implementations. In working on examples, I found many > cases where I was adding basically the same line to multiple hooks on the same class. Making the > code easier to copy-paste seems like a win. > 3. It also will be helpful if hook packages are added in the future, as they'll need a > more "generic" way to access the backing property. (See Future Scope.) Eg, "$field > = someLogic($value)" applied to a dozen different properties; it wouldn't work if it was > "$this->specificProperty = someLogic($value)". > 4. We're used to our eyes glossing over "$this->propName", as it's so > common. Having a separate name to mentally scan for to determine if a property is virtual or not > seems like it will be helpful in practice. > 5. There's precedent for it: Kotlin has almost the same functionality as we describe here, > and uses a field variable in the exact same way. > > So it's mainly an ergonomics argument rather than a technical one. "Compile time > macro" means it translates to the same AST as if you'd used $this->propName. > There's precedent for that. Constructor Property Promotion works basically the same way. With using a common name for say, $value, open the door for a library of common hook implementations (eventually)? Maybe something like: class User { // snip public string $fullName { get => FancyLibrary\fullName(...) } // snip } I could imagine something like this would be a huge boon to PHP if it automatically bound the closure.