Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127969
Message-ID: <D8D4749F-1AF5-46FF-BFAE-A52CDC1B2169@nicksdot.dev>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1282DFED-8A0F-4D0E-9B48-8ECA44B92202"
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 20:17:47 +0700
In-Reply-To: <46857A6D-5EAF-44AF-A2DE-9B40AF8DE8C8@gmail.com>
Cc: Nicolas Grekas <nicolas.grekas+php@gmail.com>,
 Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
To: Claude Pache <claude.pache@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>
 <46857A6D-5EAF-44AF-A2DE-9B40AF8DE8C8@gmail.com>
From: php@nicksdot.dev (Nick)


--Apple-Mail=_1282DFED-8A0F-4D0E-9B48-8ECA44B92202
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hey Claude,

>> 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
>=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:
>=20
> https://3v4l.org/N78An
>=20
> where the `unset(...)` is mandatory to make it =E2=80=9Cwork=E2=80=9D.
>=20
> 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).
>=20
> 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.
>=20
>=20
>> 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
>=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.
>=20
> =E2=80=94Claude

I hear you, but I still struggle to fully grasp the issue. It=E2=80=99s =
genuinely hard for me to come up with a real-world example that actually =
makes sense.
Everything I=E2=80=99ve seen so far, including the RFC example and what =
I tried myself (I gave it an honest shot), feels either very theoretical =
or entirely intentional, and thus perfectly logical in its outcome.

In one of your previous mails you brought up an example that requires =
calling a class method (read: intentionally changing class state), which =
 would result in a non-consistent value being returned when calling the =
same property more than once. I get it. But what if the user wants =
exactly that in their `readonly` class?

That said I did address your concern here (actual RFC PR branch against =
alternative; PoC):
=
https://github.com/NickSdot/php-php-src/compare/allow-readonly-hooks...Nic=
kSdot:php-php-src:readonly-hooks-strict

Larry and I agree that we don=E2=80=99t want this complexity in the =
current RFC.
Perhaps this is something for a separate `init` hook RFC?

Cheers,
Nick

(Sorry for the duplicate. I forgot to CC the list)=

--Apple-Mail=_1282DFED-8A0F-4D0E-9B48-8ECA44B92202
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;">Hey =
Claude,<div><br><div><blockquote type=3D"cite"><div =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><div><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"font-size: =
14px;">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>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><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></div></blockquote></div><=
br><div>I hear you, but I still struggle to fully grasp the issue. =
It=E2=80=99s genuinely hard for me to come up with a real-world example =
that actually makes sense.</div><div>Everything I=E2=80=99ve seen so =
far, including the RFC example and what I tried myself (I gave it an =
honest shot), feels either very theoretical or entirely intentional, and =
thus perfectly logical in its outcome.</div><div><br></div><div>In one =
of your previous mails you brought up an example that requires calling a =
class method (read: intentionally changing class state), which =
&nbsp;would result in a non-consistent value being returned when calling =
the same property more than once. I get it. But what if the user wants =
exactly that in their `readonly` class?</div><div><br></div><div>That =
said I&nbsp;<i>did</i>&nbsp;address your concern here (actual RFC PR =
branch against alternative; PoC):</div><div><a =
href=3D"https://github.com/NickSdot/php-php-src/compare/allow-readonly-hoo=
ks...NickSdot:php-php-src:readonly-hooks-strict">https://github.com/NickSd=
ot/php-php-src/compare/allow-readonly-hooks...NickSdot:php-php-src:readonl=
y-hooks-strict</a></div><div><br></div><div>Larry and I agree that we =
don=E2=80=99t want this complexity in the current RFC.</div><div>Perhaps =
this is something for a separate `init` hook =
RFC?</div><div><br></div><div><b>Cheers,</b></div><div>Nick</div></div><di=
v><br></div><div>(Sorry for the duplicate. I forgot to CC the =
list)</div></body></html>=

--Apple-Mail=_1282DFED-8A0F-4D0E-9B48-8ECA44B92202--