Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127959
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <cedce076-82de-4391-8a03-409690added9@app.fastmail.com>
Date: Tue, 8 Jul 2025 17:32:44 +0200
Message-ID: <CAOWwgp=o0PpE2b8TD9reKvO053UAu5RxTaFA7g+Huu7GozxrhQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a0f7a506396cac01"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000a0f7a506396cac01
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Larry et al.

Le mar. 8 juil. 2025 =C3=A0 17:12, Larry Garfield <larry@garfieldtech.com> =
a
=C3=A9crit :

> On Tue, Jul 1, 2025, at 9:27 AM, Tim D=C3=BCsterhus wrote:
> > Hi
> >
> > Am 2025-06-09 17:11, schrieb Larry Garfield:
> >> I also fleshed out the __get mention with an example that shows what
> >> you can already do today, and in fact could since 8.1 when readonly wa=
s
> >> introduced.  The hard guarantee of idempotency has never actually been
> >> there.  (This also speaks to Claude's concern.)
> >
> > I don't think this really resolves Claude's concern. While it is
> > certainly true that the guarantees do not currently hold, I don't
> > believe this is strong enough of a reason not to provide for stronger
> > guarantees in a *newly introduced feature*. The point of property hooks
> > is for me that =E2=80=9Cdynamic properties=E2=80=9D are easier to reaso=
n about compared
> > to `__get()`. As a user when accessing a proper `readonly` property, I
> > do not want to check if there is a property hook that might result in
> > non-readonly behavior. As an engine developer I want to be able to
> > optimize based on the `readonly`-ness of a property. Without such
> > guarantees, the =E2=80=9Creadonly=E2=80=9D keyword does not provide val=
ue to me.
>
> The only way to make the readonliness fully guaranteed would be to force =
a
> readonly property to be cached;  (IE, the hook is only called at all if t=
he
> property is uninitialized.)  But there's no obvious way to make that clea=
r
> in the code that it's what's happening.
>
> > I also believe the LazyProduct example to be broken, since lazy-loading
> > individual properties might result in an object that is internally
> > consistent if the database changes in-between.
>
> That's true with any lazy-loading scenario.  The use of hooks doesn't
> change that at all.
>


This RFC makes sense to me.

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.

I also read Tim's argument that new features could be stricter. If one
wants to be stricter and forbid extra behaviors that could be added by
either the proposed hooks or __get, then the answer is : make the class
final. This is the only real way to enforce readonly-ness in PHP.

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.

Nicolas
PS: as I keep repeating, readonly doesn't immutable at all. I know this is
written as such in the original RFC, but the concrete definition and
implementation of readonly isn't: you can set mutable objects to readonly
properties, and that means even readonly classes/properties are mutable, in
the generic case.

--000000000000a0f7a506396cac01
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi=C2=A0Larry et al.</div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">Le=C2=A0mar. 8 juil. 2025 =C3=A0=C2=A017:12, Larry Garfield &lt;<a href=
=3D"mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>&gt; a =C3=A9c=
rit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tu=
e, Jul 1, 2025, at 9:27 AM, Tim D=C3=BCsterhus wrote:<br>
&gt; Hi<br>
&gt;<br>
&gt; Am 2025-06-09 17:11, schrieb Larry Garfield:<br>
&gt;&gt; I also fleshed out the __get mention with an example that shows wh=
at <br>
&gt;&gt; you can already do today, and in fact could since 8.1 when readonl=
y was <br>
&gt;&gt; introduced.=C2=A0 The hard guarantee of idempotency has never actu=
ally been <br>
&gt;&gt; there.=C2=A0 (This also speaks to Claude&#39;s concern.)<br>
&gt;<br>
&gt; I don&#39;t think this really resolves Claude&#39;s concern. While it =
is <br>
&gt; certainly true that the guarantees do not currently hold, I don&#39;t =
<br>
&gt; believe this is strong enough of a reason not to provide for stronger =
<br>
&gt; guarantees in a *newly introduced feature*. The point of property hook=
s <br>
&gt; is for me that =E2=80=9Cdynamic properties=E2=80=9D are easier to reas=
on about compared <br>
&gt; to `__get()`. As a user when accessing a proper `readonly` property, I=
 <br>
&gt; do not want to check if there is a property hook that might result in =
<br>
&gt; non-readonly behavior. As an engine developer I want to be able to <br=
>
&gt; optimize based on the `readonly`-ness of a property. Without such <br>
&gt; guarantees, the =E2=80=9Creadonly=E2=80=9D keyword does not provide va=
lue to me.<br>
<br>
The only way to make the readonliness fully guaranteed would be to force a =
readonly property to be cached;=C2=A0 (IE, the hook is only called at all i=
f the property is uninitialized.)=C2=A0 But there&#39;s no obvious way to m=
ake that clear in the code that it&#39;s what&#39;s happening.<br>
<br>
&gt; I also believe the LazyProduct example to be broken, since lazy-loadin=
g <br>
&gt; individual properties might result in an object that is internally <br=
>
&gt; consistent if the database changes in-between.<br>
<br>
That&#39;s true with any lazy-loading scenario.=C2=A0 The use of hooks does=
n&#39;t change that at all.<br></blockquote><div><br></div><div><br></div><=
div>This RFC makes sense to me.</div><div><br></div><div>I read Claude&#39;=
s concern, and I agree with Larry&#39;s response: the engine already allows=
 readonly to be bypassed using __get. The added hook doesn&#39;t make anyth=
ing more lenient.</div><div><br></div><div>I also read Tim&#39;s argument t=
hat new features could be stricter. If one wants to be stricter and forbid =
extra behaviors that could be added by either the proposed hooks or __get, =
then the answer is : make the class final. This is the only real way to enf=
orce readonly-ness in PHP.</div><div><br></div><div>If a class is final and=
 uses readonly with=C2=A0either hooks or __get, then that&#39;s the origina=
l author&#39;s choice. There&#39;s no need for extra engine-assisted strict=
ness in this case. You cannot write such code in a non-readonly way by mist=
ake, so it has to be by intent.</div><div><br></div><div>Nicolas</div><div>=
PS: as I keep repeating, readonly doesn&#39;t immutable at all. I know this=
 is written as such in the original RFC, but the concrete definition and im=
plementation of readonly isn&#39;t: you can set mutable objects to readonly=
 properties, and that means even readonly classes/properties are mutable, i=
n the generic case.</div></div></div>

--000000000000a0f7a506396cac01--