Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122449
Precedence: bulk
MIME-Version: 1.0
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
In-Reply-To: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
Date: Wed, 21 Feb 2024 21:06:06 -0300
Message-ID: <CADK1yXL2hU39=TFk9Ye5QMjNCMd9jjoyqajnj04wTh6U2PUQng@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000dc4ddd0611ed3701"
From: deleugyn@gmail.com (Deleu)

--000000000000dc4ddd0611ed3701
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 21, 2024 at 3:58=E2=80=AFPM 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=E2=80=99s 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=E2=80=99s long, but that=E2=80=99s because we=E2=80=99re handling ever=
y edge case we could
> think of.  Properties involve dealing with both references and inheritanc=
e,
> both of which have complex implications.  We believe we=E2=80=99ve identi=
fied the
> most logical handling for all cases, though.
>
> Note the FAQ question at the end, which explains some design choices.
>
> There=E2=80=99s one outstanding question, which is slightly painful to as=
k:
> Originally, this RFC was called =E2=80=9Cproperty accessors,=E2=80=9D whi=
ch is the
> terminology used by most languages.  During early development, when we ha=
d
> 4 accessors like Swift, we changed the name to =E2=80=9Chooks=E2=80=9D to=
 better indicate
> that one was =E2=80=9Chooking into=E2=80=9D the property lifecycle.  Howe=
ver, later
> refinement brought it back down to 2 operations, get and set.  That makes
> the =E2=80=9Chooks=E2=80=9D name less applicable, and inconsistent with w=
hat 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=E2=
=80=99s
> 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
>

This is a long, huge and comprehensive work, congratz to the authors.

It clearly shows that so much thought and work has been put into it that it
makes me cautious to even ask for further clarification.

> Javascript have similar features via a different syntax, although that
syntax would not be viable for PHP

Why not?

```
final class Foo
{
    public string $bar;

    public function get bar(): string
    {
        // custom getter
    }

    public function set bar(string $value): void
    {
        // custom setter
    }
}
```

It feels quite a natural syntax for PHP and from someone oblivious to the
internal work, it appears to be a slight marginal change to the existing
RFC. Given the extensive work of this RFC, it seems pretty obvious that
this syntax will not work, I just don't know why.

--=20
Marco Deleu

--000000000000dc4ddd0611ed3701
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 21, 2024 at 3:58=E2=80=AF=
PM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfi=
eldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex">Hello again, fine Inte=
rnalians.<br>
<br>
After much on-again/off-again work, Ilija and I are back with a more polish=
ed property access hooks/interface properties RFC.=C2=A0 It=E2=80=99s 99% u=
nchanged from last summer; the PR is now essentially complete and more robu=
st, and we were able to squish the last remaining edge cases.<br>
<br>
Baring any major changes, we plan to bring this to a vote in mid-March.<br>
<br>
<a href=3D"https://wiki.php.net/rfc/property-hooks" rel=3D"noreferrer" targ=
et=3D"_blank">https://wiki.php.net/rfc/property-hooks</a><br>
<br>
It=E2=80=99s long, but that=E2=80=99s because we=E2=80=99re handling every =
edge case we could think of.=C2=A0 Properties involve dealing with both ref=
erences and inheritance, both of which have complex implications.=C2=A0 We =
believe we=E2=80=99ve identified the most logical handling for all cases, t=
hough.<br>
<br>
Note the FAQ question at the end, which explains some design choices.<br>
<br>
There=E2=80=99s one outstanding question, which is slightly painful to ask:=
 Originally, this RFC was called =E2=80=9Cproperty accessors,=E2=80=9D whic=
h is the terminology used by most languages.=C2=A0 During early development=
, when we had 4 accessors like Swift, we changed the name to =E2=80=9Chooks=
=E2=80=9D to better indicate that one was =E2=80=9Chooking into=E2=80=9D th=
e property lifecycle.=C2=A0 However, later refinement brought it back down =
to 2 operations, get and set.=C2=A0 That makes the =E2=80=9Chooks=E2=80=9D =
name less applicable, and inconsistent with what other languages call it.<b=
r>
<br>
However, changing it back at this point would be a non-small amount of grun=
t work. There would be no functional changes from doing so, but it=E2=80=99=
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.<br>
<br>
-- <br>
=C2=A0 Larry Garfield<br>
=C2=A0 <a href=3D"mailto:larry@garfieldtech.com" target=3D"_blank">larry@ga=
rfieldtech.com</a><br>
</blockquote></div><div><br></div>This is a long, huge and comprehensive wo=
rk, congratz to the authors.<div><br></div><div>It clearly shows that so mu=
ch thought and work has been put into it that it makes me cautious to even =
ask for further clarification.=C2=A0</div><div><br></div><div>&gt;=C2=A0Jav=
ascript have similar features via a different syntax, although that syntax =
would not be viable for PHP</div><div><br></div><div>Why not?</div><div><br=
></div><div>```</div><div>final class Foo</div><div>{</div><div>=C2=A0 =C2=
=A0 public string $bar;</div><div><br></div><div>=C2=A0 =C2=A0 public funct=
ion get bar(): string</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 // custom getter</div><div>=C2=A0 =C2=A0 }</div><div><br></div><=
div><div>=C2=A0 =C2=A0 public function set bar(string $value): void</div><d=
iv>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // custom setter</=
div><div>=C2=A0 =C2=A0 }</div></div><div>}</div><div>```</div><div><br></di=
v><div>It feels quite a natural syntax for PHP and from someone oblivious t=
o the internal work, it appears to be a slight marginal change to the exist=
ing RFC. Given the extensive work of this RFC, it seems pretty obvious that=
 this syntax will not work, I just don&#39;t know why.<br clear=3D"all"><di=
v><br></div><span class=3D"gmail_signature_prefix">-- </span><br><div dir=
=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div dir=3D"ltr"><div d=
ir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"l=
tr">Marco Deleu</div></div></div></div></div></div></div></div></div></div>

--000000000000dc4ddd0611ed3701--