On Mon, Jun 10, 2024, at 12:33 PM, Valentin Udaltsov wrote: > On Sunday, 9 June, 2024 at 19:03, Nikita Popov <p...@npopov.com> wrote: >> __ >> On Mon, Apr 15, 2024, at 18:43, Larry Garfield wrote: >>> The vote for the Property Hooks RFC is now open: >>> >>> https://wiki.php.net/rfc/property-hooks >>> >>> Voting will close on Monday 29 April, afternoonish Chicago time. >> >> The other thing that stood out to me are the short-hand notations using =>. >> There was a prior RFC on the topic >> (https://wiki.php.net/rfc/short-functions), which has been declined. That >> RFC would have introduced => ... as a general shorthand for { return ...; }. >> >> The shorthand notation for get is compatible with that formulation. However, >> the shorthand notation for set is not. In that case => ... isn't short for { >> return ...; }, but rather for { $this->prop = ...; }. >> >> This seems pretty unfortunate to me, and possibly closes the door on >> revisiting a general short function syntax in the future. Mostly I'm >> scratching my head at why this was included in the proposal at all, as I >> would not expect this use of the set hook to be common enough to justify a >> shorthand. The common case is a guard that checks the value without >> modifying it.
I'm a little surprised to hear you say that, since you voted against short-functions at the time. :-) I would love to try again on those if there's enough change in opinion to make it worthwhile, as I do think it's useful. The reason we included short-set, aside from consistency, is that people really seemed to want a "return to assign" behavior, and that was the most logical way to do it. It's also more compact for when a set hook is inlined into a promoted constructor property, which I suspect will be not uncommon. For "validate or error" use cases, a ternary isn't ideal but it will get the job done, and there are several examples of that in the RFC. If we find that "validate but don't modify" is an especially common case, then we should look into a more dedicated syntax for property Constraints / Guards. (I have some ideas there, but nothing ready for public consumption.) I don't think the current hook syntax would preclude short-functions generally, though. The syntax is the same, the behavior is the same, all that's really different from the typical case is the extra "and the thing it evaluates to gets assigned." Which is exactly what several people asked for. So I don't see how it is really going to cause a conflict. (Side note: If anyone has warmed to short-functions since it was last brought up let me know. I have no idea how to gauge if the zeitgeist has changed since then to make another attempt worthwhile.) >> >> Regards, >> Nikita > Correct me if I'm wrong, but here's how I understand the short-hand > notation in setter hook in combination with > https://wiki.php.net/rfc/short-functions: > > ``` > final class Foo > { > // Before > public string $x { > set { > $this->x = $this->transformX($value); > } > } > > private function transformX(string $value): string => trim($value); > > // After > public string $x { > set => trim($value); > } > } > ``` > > So it's kinda consistent if you say that only the right side of the > property assignment is replaced with short-hand notation, not the whole > assignment. And then `$this->x =` is implicit. Essentially that, yes. --Larry Garfield
