Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127962
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>
In-Reply-To: <f4e4057b19a5ed9de7ad92215e78d58c@bastelstu.be>
Date: Wed, 9 Jul 2025 08:30:31 +0200
Message-ID: <CAOWwgpnNUN6Ci=bJ=AHAqTVNmebvSV4fV-d+_rZ4RziaiUKxYg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000058c63c0639793735"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--00000000000058c63c0639793735
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tim,

Le mar. 1 juil. 2025 =C3=A0 16:29, Tim D=C3=BCsterhus <tim@bastelstu.be> a =
=C3=A9crit :

> 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 was
> > 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 reason =
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 value=
 to me.
>
> 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.


Here are two situations that are perfectly valid use cases for the example:
- event-sourced / versioned entities in the DB, where the state of an
object cannot change in the backend
- lazy-parsed network payloads, where one parses only part of some JSONs on
demand (mongodb and symfony/json-streamer do such things already)

Nicolas

--00000000000058c63c0639793735
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Tim,</div><br><div class=3D"gmail_quot=
e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar.=
 1 juil. 2025 =C3=A0=C2=A016:29, Tim D=C3=BCsterhus &lt;<a href=3D"mailto:t=
im@bastelstu.be">tim@bastelstu.be</a>&gt; a =C3=A9crit=C2=A0:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
Am 2025-06-09 17:11, schrieb Larry Garfield:<br>
&gt; I also fleshed out the __get mention with an example that shows what <=
br>
&gt; you can already do today, and in fact could since 8.1 when readonly wa=
s <br>
&gt; introduced.=C2=A0 The hard guarantee of idempotency has never actually=
 been <br>
&gt; there.=C2=A0 (This also speaks to Claude&#39;s concern.)<br>
<br>
I don&#39;t think this really resolves Claude&#39;s concern. While it is <b=
r>
certainly true that the guarantees do not currently hold, I don&#39;t <br>
believe this is strong enough of a reason not to provide for stronger <br>
guarantees in a *newly introduced feature*. The point of property hooks <br=
>
is for me that =E2=80=9Cdynamic properties=E2=80=9D are easier to reason ab=
out compared <br>
to `__get()`. As a user when accessing a proper `readonly` property, I <br>
do not want to check if there is a property hook that might result in <br>
non-readonly behavior. As an engine developer I want to be able to <br>
optimize based on the `readonly`-ness of a property. Without such <br>
guarantees, the =E2=80=9Creadonly=E2=80=9D keyword does not provide value t=
o me.<br>
<br>
I also believe the LazyProduct example to be broken, since lazy-loading <br=
>
individual properties might result in an object that is internally <br>
consistent if the database changes in-between.</blockquote><div><br></div><=
div>Here are two situations that are perfectly valid=C2=A0use cases for the=
 example:</div><div>- event-sourced / versioned entities in the DB, where t=
he state of an object cannot change in the backend</div><div>- lazy-parsed =
network payloads, where one parses only part of some JSONs on demand (mongo=
db and symfony/json-streamer do such things already)</div><div><br></div><d=
iv>Nicolas</div></div></div>

--00000000000058c63c0639793735--