Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122451
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: Thu, 22 Feb 2024 09:34:40 +0100
Message-ID: <CAPzBOBOSDamBevodU71C_YRnz6yZKrbFj_1ojKNnPubWxpbqvg@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>, Marco Pivetta <ocramius@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Wed, Feb 21, 2024 at 7:59=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 poli=
shed property access hooks/interface properties RFC.  It=E2=80=99s 99% unch=
anged 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 refere=
nces and inheritance, both of which have complex implications.  We believe =
we=E2=80=99ve identified 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 wh=
ich is the terminology used by most languages.  During early development, w=
hen 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 the p=
roperty lifecycle.  However, later refinement brought it back down to 2 ope=
rations, get and set.  That makes the =E2=80=9Chooks=E2=80=9D name less app=
licable, and inconsistent with what other languages call it.
>
> However, changing it back at this point would be a non-small amount of gr=
unt 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 befo=
re putting in the effort.
>
> --
>   Larry Garfield
>   larry@garfieldtech.com

This is a reply to Marco (https://externals.io/message/122445#122449)
for which I didn't actually receive the email but got an email from
the list that I didn't receive the email -- seems like it would have
been simpler and more correct to resend the email. That is a bit
weird, but whatever.

> Given the extensive work of this RFC, it seems pretty obvious that
> this syntax will not work, I just don't know why.

I feel like the syntax is natural, coming from other languages with
this feature. However, I really do appreciate the example Marco gives
as it feels very idiomatically PHP with all the getters/setters we are
used to writing. It also means a pretty simple "just add a space and
downcase" to switch from traditional methods to getters/setters to
hooks, which could be really nice.