Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123566
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-497-g97f96844c-fm-20240526.001-g97f96844
Precedence: bulk
MIME-Version: 1.0
Message-ID: <dd83acb1-498a-4332-91bf-920595bd8a77@app.fastmail.com>
In-Reply-To: 
 <CAPyeZ4NuZfdVQOK=9F3Q2Nb+=_MqG9fKtg0XxJU_=CR1GbYqHA@mail.gmail.com>
References: <caf753e7-99e4-486f-9983-dff83f8a40d7@app.fastmail.com>
 <834cb6c7-c6ae-4b59-b022-a43793f842a3@app.fastmail.com>
 <CAPyeZ4NuZfdVQOK=9F3Q2Nb+=_MqG9fKtg0XxJU_=CR1GbYqHA@mail.gmail.com>
Date: Mon, 10 Jun 2024 14:19:38 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC][Vote] Property Hooks
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jun 10, 2024, at 12:33 PM, Valentin Udaltsov wrote:
> On Sunday, 9 June, 2024=E2=80=AFat 19:03, Nikita Popov <php@npopov.com=
> wrote:
>> __
>> On Mon, Apr 15, 2024, at 18:43, Larry Garfield wrote:
>>> The vote for the Property Hooks RFC is now open:
>>>=20
>>> https://wiki.php.net/rfc/property-hooks
>>>=20
>>> Voting will close on Monday 29 April, afternoonish Chicago time.
>>=20
>> The other thing that stood out to me are the short-hand notations usi=
ng =3D>. There was a prior RFC on the topic (https://wiki.php.net/rfc/sh=
ort-functions), which has been declined. That RFC would have introduced =
=3D> ... as a general shorthand for { return ...; }.
>>=20
>> The shorthand notation for get is compatible with that formulation. H=
owever, the shorthand notation for set is not. In that case =3D> ... isn=
't short for { return ...; }, but rather for { $this->prop =3D ...; }.
>>=20
>> This seems pretty unfortunate to me, and possibly closes the door on =
revisiting a general short function syntax in the future. Mostly I'm scr=
atching my head at why this was included in the proposal at all, as I wo=
uld 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 mod=
ifying it.

I'm a little surprised to hear you say that, since you voted against sho=
rt-functions at the time. :-)  I would love to try again on those if the=
re'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 m=
ost 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 n=
ot uncommon.  For "validate or error" use cases, a ternary isn't ideal b=
ut it will get the job done, and there are several examples of that in t=
he 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 Constrai=
nts / Guards.  (I have some ideas there, but nothing ready for public co=
nsumption.)

I don't think the current hook syntax would preclude short-functions gen=
erally, though.  The syntax is the same, the behavior is the same, all t=
hat's really different from the typical case is the extra "and the thing=
 it evaluates to gets assigned."  Which is exactly what several people a=
sked 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 br=
ought up let me know. I have no idea how to gauge if the zeitgeist has c=
hanged since then to make another attempt worthwhile.)

>>=20
>> Regards,
>> Nikita

> Correct me if I'm wrong, but here's how I understand the short-hand=20
> notation in setter hook in combination with=20
> https://wiki.php.net/rfc/short-functions:
>
> ```
> final class Foo
> {
>     // Before
>     public string $x {
>         set {
>             $this->x =3D $this->transformX($value);
>         }
>     }
>
>     private function transformX(string $value): string =3D> trim($valu=
e);
>
>     // After
>     public string $x {
>         set =3D> trim($value);
>     }
> }
> ```
>
> So it's kinda consistent if you say that only the right side of the=20
> property assignment is replaced with short-hand notation, not the whol=
e=20
> assignment. And then `$this->x =3D` is implicit.

Essentially that, yes.

--Larry Garfield