Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123564
Precedence: bulk
MIME-Version: 1.0
References: <caf753e7-99e4-486f-9983-dff83f8a40d7@app.fastmail.com> <834cb6c7-c6ae-4b59-b022-a43793f842a3@app.fastmail.com>
In-Reply-To: <834cb6c7-c6ae-4b59-b022-a43793f842a3@app.fastmail.com>
Date: Sun, 9 Jun 2024 10:52:38 -0600
Message-ID: <CAM7F2-9smZYwghk7wpGrLjX2uKar--QHtOf1ze52KpDv8Ai5CQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Vote] Property Hooks
To: Nikita Popov <php@npopov.com>
Cc: Larry Garfield <larry@garfieldtech.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e432f8061a77dc7e"
From: lnearwaju@gmail.com (Lanre)

--000000000000e432f8061a77dc7e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Personally I still think we should have used TS/JS syntax for computed
properties. PHP is much closer to typescript than Java/C# and we already
have support for modifiers. Slightly more verbose but these issues would be
non-existent.

On Sun, Jun 9, 2024 at 10:03=E2=80=AFAM 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:
>
> https://wiki.php.net/rfc/property-hooks
>
> Voting will close on Monday 29 April, afternoonish Chicago time.
>
>
> I know I'm a few months late on this one, but I figured I'd still leave a
> couple of thoughts... Overall, the proposal is well thought out and does
> address many of the reservations I had about my original accessors propos=
al.
>
> One of the more interesting choices in this proposal is to base whether
> the property is virtual or backed on the presence of a "$this->prop"
> reference in the accessor implementation. I think that, conceptually at
> least, this is a good choice.
>
> What I find concerning though, is that the presence/absence of such a
> reference also affects the meaning of the get and set hooks. If the
> property is virtual and it only has get, then the property cannot be set.
> If the property is backed and only has get, then the property *can* be se=
t.
> A no-op setter is implied. (Similar for only having a set hook.)
>
> This has the unfortunate consequence that you actually have to look at th=
e
> accessor implementation to determine the API of the class -- only looking
> at the "prototypes" (i.e. signatures without implementation bodies) is no
> longer sufficient! This seems both unfortunate and unprecedented.
>
> This could have been avoided by still requiring an explicit no-op "set;"
> at the expensive of some additional verbosity.
>
> The other thing that stood out to me are the short-hand notations using
> =3D>. There was a prior RFC on the topic (
> https://wiki.php.net/rfc/short-functions), which has been declined. That
> RFC would have introduced =3D> ... 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 =3D> ... isn=
't
> short for { return ...; }, but rather for { $this->prop =3D ...; }.
>
> 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.
>
> Putting this to the "would this shorthand have passed if it were
> introduced by a separate RFC on top of the base implementation" test, I
> think the answer would have been a clear "no".
>
> Regards,
> Nikita
>

--000000000000e432f8061a77dc7e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Personally I still think we should have u=
sed TS/JS syntax for computed properties. PHP is much closer to typescript=
=C2=A0than Java/C# and we already have support for modifiers. Slightly more=
 verbose but these issues would be non-existent.</div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 9, 2024 at 10:0=
3=E2=80=AFAM Nikita Popov &lt;<a href=3D"mailto:php@npopov.com">php@npopov.=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div class=3D"msg-8075116714226849488"><u></u><div><div>On Mon, Apr 15, =
2024, at 18:43, Larry Garfield wrote:<br></div><blockquote type=3D"cite" id=
=3D"m_-8075116714226849488qt"><div>The vote for the Property Hooks RFC is n=
ow open:<br></div><div><br></div><div><a href=3D"https://wiki.php.net/rfc/p=
roperty-hooks" target=3D"_blank">https://wiki.php.net/rfc/property-hooks</a=
><br></div><div><br></div><div>Voting will close on Monday 29 April, aftern=
oonish Chicago time.<br></div></blockquote><div><br></div><div>I know I&#39=
;m a few months late on this one, but I figured I&#39;d still leave a coupl=
e of thoughts... Overall, the proposal is well thought out and does address=
 many of the reservations I had about my original accessors proposal.<br></=
div><div><br></div><div>One of the more interesting choices in this proposa=
l is to base whether the property is virtual or backed on the presence of a=
 &quot;$this-&gt;prop&quot; reference in the accessor implementation. I thi=
nk that, conceptually at least, this is a good choice.<br></div><div><br></=
div><div>What I find concerning though, is that the presence/absence of suc=
h a reference also affects the meaning of the get and set hooks. If the pro=
perty is virtual and it only has get, then the property cannot be set. If t=
he property is backed and only has get, then the property *can* be set. A n=
o-op setter is implied. (Similar for only having a set hook.)<br></div><div=
><br></div><div>This has the unfortunate consequence that you actually have=
 to look at the accessor implementation to determine the API of the class -=
- only looking at the &quot;prototypes&quot; (i.e. signatures without imple=
mentation bodies) is no longer sufficient! This seems both unfortunate and =
unprecedented.<br></div><div><br></div><div>This could have been avoided by=
 still requiring an explicit no-op &quot;set;&quot; at the expensive of som=
e additional verbosity.<br></div><div><br></div><div>The other thing that s=
tood out to me are the short-hand notations using =3D&gt;. There was a prio=
r RFC on the topic (<a href=3D"https://wiki.php.net/rfc/short-functions" ta=
rget=3D"_blank">https://wiki.php.net/rfc/short-functions</a>), which has be=
en declined. That RFC would have introduced =3D&gt; ... as a general shorth=
and for { return ...; }.<br></div><div><br></div><div>The shorthand notatio=
n for get is compatible with that formulation. However, the shorthand notat=
ion for set is not. In that case =3D&gt; ... isn&#39;t short for { return .=
..; }, but rather for { $this-&gt;prop =3D ...; }.<br></div><div><br></div>=
<div>This seems pretty unfortunate to me, and possibly closes the door on r=
evisiting a general short function syntax in the future. Mostly I&#39;m scr=
atching 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 short=
hand. The common case is a guard that checks the value without modifying it=
.<br></div><div><br></div><div>Putting this to the &quot;would this shortha=
nd have passed if it were introduced by a separate RFC on top of the base i=
mplementation&quot; test, I think the answer would have been a clear &quot;=
no&quot;.<br></div><div><br></div><div>Regards,<br></div><div>Nikita<br></d=
iv></div></div></blockquote></div></div>

--000000000000e432f8061a77dc7e--