On Thu, Feb 22, 2024 at 1:03 AM Pierre <pierre-...@processus.org> wrote: > > Le 21/02/2024 à 19:55, Larry Garfield a écrit : > > Hello again, fine Internalians. > > > > After much on-again/off-again work, Ilija and I are back with a more > > polished property access hooks/interface properties RFC. It’s 99% > > unchanged from last summer; the PR is now essentially complete and more > > robust, and we were able to squish the last remaining edge cases. > > > > Baring any major changes, we plan to bring this to a vote in mid-March. > > > > https://wiki.php.net/rfc/property-hooks > > > > It’s long, but that’s because we’re handling every edge case we could think > > of. Properties involve dealing with both references and inheritance, both > > of which have complex implications. We believe we’ve identified the most > > logical handling for all cases, though. > > > > Note the FAQ question at the end, which explains some design choices. > > > > There’s one outstanding question, which is slightly painful to ask: > > Originally, this RFC was called “property accessors,” which is the > > terminology used by most languages. During early development, when we had > > 4 accessors like Swift, we changed the name to “hooks” to better indicate > > that one was “hooking into” the property lifecycle. However, later > > refinement brought it back down to 2 operations, get and set. That makes > > the “hooks” name less applicable, and inconsistent with what other > > languages call it. > > > > However, changing it back at this point would be a non-small amount of > > grunt work. There would be no functional changes from doing so, but it’s > > lots of renaming things both in the PR and the RFC. We are willing to do so > > if the consensus is that it would be beneficial, but want to ask before > > putting in the effort. > > > Yes please ! Pass ! > > I don't have voting rights, but we need this. > > Cheers, > > Pierre R.
I apologize if this has already been covered: > There are two shorthand notations supported, beyond the optional argument to > set. > First, if a hook's body is a single expression, then the { } and return > statement may be omitted and replaced with =>, just like with arrow functions. Does => do any special auto-capturing of variables like arrow functions or is it just a shorthand? Also, is this a meaningful shorthand to the example a little further down: public string $phone { set = $this->sanitizePhone(...); } or do we always have to write it out? public string $phone { set => $field = $this->sanitizePhone($value); } Would __PROPERTY__ be set inside sanitizePhone() as well? You mention several ways values are displayed (whether or not they use the get-hook), but what does the default implementation of `__debugInfo()` look like now (or is that out of scope or a silly question?) For attributes, it would be nice to be able to target hooks specifically with attributes instead of also all methods (e.g., a Attribute::TARGET_GET_HOOK const). For example, if I were writing a serialization library, I may want to specify #[UseRawValue] only on getters to ensure that only the raw value is serialized instead of the getter (which may be specific to the application logic, or #[GetFromMethod] to tell the serialization library to get the value from a completely different method. It wouldn't make sense to target just any method with that attribute.