On Mon, Jun 10, 2024, at 12:33 PM, Valentin Udaltsov wrote:
> On Sunday, 9 June, 2024 at 19:03, Nikita Popov <[email protected]> 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