Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122445
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-153-g7e3bb84806-fm-20240215.007-g7e3bb848
Precedence: bulk
MIME-Version: 1.0
Message-ID: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com>
Date: Wed, 21 Feb 2024 18:55:49 +0000
To: "php internals" <internals@lists.php.net>
Subject: [PHP-DEV] [RFC[ Property accessor hooks, take 2
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

Hello again, fine Internalians.

After much on-again/off-again work, Ilija and I are back with a more pol=
ished 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 eve=
ry edge case we could think of.  Properties involve dealing with both re=
ferences and inheritance, both of which have complex implications.  We b=
elieve 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 a=
sk: Originally, this RFC was called =E2=80=9Cproperty accessors,=E2=80=9D=
 which is the terminology used by most languages.  During early developm=
ent, when we had 4 accessors like Swift, we changed the name to =E2=80=9C=
hooks=E2=80=9D to better indicate that one was =E2=80=9Chooking into=E2=80=
=9D the property lifecycle.  However, later refinement brought it back d=
own to 2 operations, get and set.  That makes the =E2=80=9Chooks=E2=80=9D=
 name less applicable, and inconsistent with what other languages call i=
t.

However, changing it back at this point would be a non-small amount of g=
runt 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 willi=
ng to do so if the consensus is that it would be beneficial, but want to=
 ask before putting in the effort.

--=20
  Larry Garfield
  larry@garfieldtech.com