Re: [RFC[ Property accessor hooks, take 2

On Wed, 21 Feb 2024 at 18:56, Larry Garfield <larry@garfieldtech.com> wrote: > 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. > > -- > Larry Garfield > larry@garfieldtech.com I remember the previous RFC. cant remeber why it was decline, but i hope this one passes, I know the PHP community has been asking for native getter/setters instead of __get __set for a while, since 7.0 was released at least. A few things i was interested to get the idea around. Was it thought about for the set{} for it to return the value to set the property to instead implicitly setting its own field? eg ``` public string $name { set { return usfirst($value); } } ``` Where the value returned in the set is what the property will be set to?