Re: [RFC[ Property accessor hooks, take 2

On Thu, Feb 22, 2024 at 1:03 AM Pierre <pierre-php@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.