Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127966
Message-ID: <46857A6D-5EAF-44AF-A2DE-9B40AF8DE8C8@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_EAF221E1-85D8-4A04-8B4D-AD4D2FC11E04"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
Date: Wed, 9 Jul 2025 12:52:48 +0200
In-Reply-To: <CAOWwgp=o0PpE2b8TD9reKvO053UAu5RxTaFA7g+Huu7GozxrhQ@mail.gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com>
 <CAMzRQTdDNsF_LPpNKUbVROTWjDbN2uDw-j2PrL3xp7qASA62GA@mail.gmail.com>
 <be533915-2b0d-460d-a5ea-76fe98fc4080@app.fastmail.com>
 <f4e4057b19a5ed9de7ad92215e78d58c@bastelstu.be>
 <cedce076-82de-4391-8a03-409690added9@app.fastmail.com>
 <CAOWwgp=o0PpE2b8TD9reKvO053UAu5RxTaFA7g+Huu7GozxrhQ@mail.gmail.com>
From: claude.pache@gmail.com (Claude Pache)


--Apple-Mail=_EAF221E1-85D8-4A04-8B4D-AD4D2FC11E04
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 8 juil. 2025 =C3=A0 17:32, Nicolas Grekas =
<nicolas.grekas+php@gmail.com> a =C3=A9crit :
>=20
> I read Claude's concern, and I agree with Larry's response: the engine =
already allows readonly to be bypassed using __get. The added hook =
doesn't make anything more lenient.
>=20

It is true that readonly could be bypassed by __get(); but this is a =
legacy behaviour, and you have to take an explicit step to make it =
possible. For those unaware of the awful hack, here is a minimal test =
case:

https://3v4l.org/N78An

where the `unset(...)` is mandatory to make it =E2=80=9Cwork=E2=80=9D.

Are we obligated to sanction shortcomings of legacy concepts in newly =
introduced concepts that are supposed to replace them? Or can we do =
something better? I=E2=80=99ve outlined in a previous email what I think =
is a better design for such situation (namely an `init` hook).

Also, the fact that __get() is not yet deprecated means that we can =
still use the aforementioned hack until/unless we=E2=80=99ve implemented =
a proper solution. In the worst case, you can still use a non-readonly =
hooked property and document the intended invariants in phpdoc.


> If a class is final and uses readonly with either hooks or __get, then =
that's the original author's choice. There's no need for extra =
engine-assisted strictness in this case. You cannot write such code in a =
non-readonly way by mistake, so it has to be by intent.
>=20

Enforcing as strictly as possible its intended invariants is a good =
design for a robust language. Yes, it implies that users cannot (or can =
hardly) escape annoying constraints. For example, you can=E2=80=99t =
extend a final class, even if you think that you have good reason for =
it, like constructing a mock object.

=E2=80=94Claude=

--Apple-Mail=_EAF221E1-85D8-4A04-8B4D-AD4D2FC11E04
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>Le 8 juil. 2025 =C3=A0 17:32, Nicolas Grekas =
&lt;nicolas.grekas+php@gmail.com&gt; a =C3=A9crit :</div><br =
class=3D"Apple-interchange-newline"><div><div style=3D"caret-color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: =
normal; font-variant-caps: normal; font-weight: 400; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;">I read Claude's concern, and I agree with =
Larry's response: the engine already allows readonly to be bypassed =
using __get. The added hook doesn't make anything more lenient.</div><br =
class=3D"Apple-interchange-newline"></div></blockquote></div><br><div>It =
is true that readonly could be bypassed by __get(); but this is a legacy =
behaviour, and you have to take an explicit step to make it possible. =
For those unaware of the awful hack, here is a minimal test =
case:</div><div><br></div><div><a =
href=3D"https://3v4l.org/N78An">https://3v4l.org/N78An</a></div><div><br><=
/div><div>where the `unset(...)` is mandatory to make it =
=E2=80=9Cwork=E2=80=9D.</div><div><br></div><div>Are we obligated to =
sanction shortcomings of legacy concepts in newly introduced concepts =
that are supposed to replace them? Or can we do something better? I=E2=80=99=
ve outlined in a previous email what I think is a better design for such =
situation (namely an `init` hook).</div><div><br></div><div>Also, the =
fact that __get() is not yet deprecated means that we can still use the =
aforementioned hack until/unless we=E2=80=99ve implemented a proper =
solution. In the worst case, you can still use a non-readonly hooked =
property and document the intended invariants in =
phpdoc.</div><div><br></div><div><br></div><div><div></div></div><blockquo=
te type=3D"cite"><div><div>If a class is final and uses readonly with =
either hooks or __get, then that's the original author's choice. There's =
no need for extra engine-assisted strictness in this case. You cannot =
write such code in a non-readonly way by mistake, so it has to be by =
intent.</div></div><div><br></div></blockquote><div><br></div>Enforcing =
as strictly as possible its intended invariants is a good design for a =
robust language. Yes, it implies that users cannot (or can hardly) =
escape annoying constraints. For example, you can=E2=80=99t extend a =
final class, even if you think that you have good reason for it, like =
constructing a mock =
object.<div><br></div><div>=E2=80=94Claude</div></body></html>=

--Apple-Mail=_EAF221E1-85D8-4A04-8B4D-AD4D2FC11E04--