Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128111
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> <CAOWwgp=o0PpE2b8TD9reKvO053UAu5RxTaFA7g+Huu7GozxrhQ@mail.gmail.com>
 <46857A6D-5EAF-44AF-A2DE-9B40AF8DE8C8@gmail.com> <41241c3d-a601-4fb8-9f32-976bea3b660e@app.fastmail.com>
 <308e51e9-ebc9-4ab1-a727-46854b27701f@bastelstu.be>
In-Reply-To: <308e51e9-ebc9-4ab1-a727-46854b27701f@bastelstu.be>
Date: Fri, 18 Jul 2025 16:25:23 +0200
Message-ID: <CAMkukMxjTaebvr+wnqOBWbGhgxDiqNRsbNV+WepNoBmaeV9z0A@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="00000000000030b056063a34e694"
From: hello@faizanakram.me (Faizan Akram Dar)

--00000000000030b056063a34e694
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 18 Jul 2025, 15:16 Tim D=C3=BCsterhus, <tim@bastelstu.be> wrote:

> Hi
>
> On 7/9/25 16:05, Larry Garfield wrote:
> > 1. `readonly` bills itself as immutability, but it fundamentally is
> not.  There are at least two loopholes: __get and a mutable object saved =
to
> a property.  So while it offering immutability guarantees is nice in
> theory, it's simply not true in practice.  `readonly` has always been
> misnamed; it should really be `writeonce`, because that's all it is.  (On=
ce
> again, this is likely the most poorly designed feature we've added in man=
y
> years.)
>
> No, readonly is readonly, not writeonce. Stop trying to redefine
> readonly as writeonce to justify bad design decisions.
>
> Readonly guarantees that once I successfully read from a property that
> I'll get the same thing out on subsequent reads and I consider this to
> be valuable and strongly disagree on the "most poorly designed feature"
> bit.
>
> Yes, I understand that __get() currently is an exception to that
> guarantee, but that does not mean that further exceptions should be
> added to water down readonly into something that is completely useless.
>
> > 2. In 8.4, if a class is marked `readonly`, you basically forbid it fro=
m
> having any hooks of any kind, even though you absolutely can honor the
> write-once-ness of the properties while still having hooks.  And that
> applies to child classes, too, because `readonly`-ness inherits.  So addi=
ng
> a single hook means you have to move the readonly to all the other
> properties individually, which if inheritance is involved you cannot do.
> >
> > The RFC aims to address point 2 in a way that still respects point 1,
> but only point 1 as it actually is (write-once), not as we wish it to be
> (immutability).
>
> Readonly is immutability of values (or in other words immutability of
> identity). For objects this means immutability of the object handle, for
> other types this means actual immutability.
>
> I also feel compelled to mention at this point that the commonly
> repeated statement of "Objects are passed by reference" is incorrect.
> It's that "the object handle is passed by value". And then it's fully
> consistent with how readonly works as of now.
>
> > * set hooks for validation, which don't impact writeonce-ness.  I think
> everyone seems on board with that.
>
> Yes, allowing set hooks for readonly properties seems sound to me.
>
> > * Lazy computed properties.  I use these a ton, even for internal
> caching purposes.  99% of the time I cache them because my objects are
> practically immutable, and $this->foo ??=3D whatever is an easy enough
> pattern.  (If they're not cached then it would be a virtual property, whi=
ch
> we're not dealing with for now.)  As long as you're caching it in that
> fashion, the write-once-ness still ends up respected.
> >
> > Honestly, Nick tried to come up with examples yesterday while we were
> talking that would not fit into one of those two categories, and for ever=
y
> one of them my answer was "if your code is already that badly designed,
> there's nothing we can do for you." :-)
>
> It's nice to hear that there are no other usecases for hooks on readonly
> properties, since this means that we can just allow the 'set' hook and
> add an 'init' hook for the lazy computation use-case without needing to
> violate the semantics of `readonly` by allowing a `get` hook.
>
> > An init hook would be clearer, certainly, though it also has its own
> edge cases.  Can you set something that has an init hook?  What happens i=
f
> there's both a get and init hook?  These probably have answers that could
> be sorted out, but that's a different question from "why the <censored>
> does a readonly class forbid me using even rudimentary hooks???"
>
> Not clearer. It would be the only thing that is semantically sound.
> While it certainly needs careful consideration of semantics to ensure
> there are no edge cases, figuring this out should be much easier than
> intentionally introducing edge cases via a get hook.
>
> As to your questions: The init hook is triggered when reading from a
> property that is in the uninitialized state. The return value of the
> hook is stored in the property and returned as the result of the read
> operation. Having an init hook implies the property is non-virtual.
>
> - Yes, you can set something that has an init hook. Setting means that
> the property will no longer be uninitialized, which means that the init
> hook will no longer be called.
> - If there is both a get and an init hook, the init hook will be called
> when the backing store is uninitialized. The result of the init hook
> will then also go through the get hook. On subsequent reads only the get
> hook will be called.
>
> Best regards
> Tim D=C3=BCsterhus
>


Hi Tim,

The problem with allowing only set hooks is that readonly class won't be
compatible with hooks, I think that is one of the main motivations behind
this RFC.




Faizan Akram Dar
faizanakram.me

--00000000000030b056063a34e694
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div></div><div data-smartmail=3D"gmail_signature"><=
div dir=3D"ltr"><div><div dir=3D"ltr"></div></div><br></div></div><div clas=
s=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_att=
r">On Fri, 18 Jul 2025, 15:16 Tim D=C3=BCsterhus, &lt;<a href=3D"mailto:tim=
@bastelstu.be">tim@bastelstu.be</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Hi<br>
<br>
On 7/9/25 16:05, Larry Garfield wrote:<br>
&gt; 1. `readonly` bills itself as immutability, but it fundamentally is no=
t.=C2=A0 There are at least two loopholes: __get and a mutable object saved=
 to a property.=C2=A0 So while it offering immutability guarantees is nice =
in theory, it&#39;s simply not true in practice.=C2=A0 `readonly` has alway=
s been misnamed; it should really be `writeonce`, because that&#39;s all it=
 is.=C2=A0 (Once again, this is likely the most poorly designed feature we&=
#39;ve added in many years.)<br>
<br>
No, readonly is readonly, not writeonce. Stop trying to redefine <br>
readonly as writeonce to justify bad design decisions.<br>
<br>
Readonly guarantees that once I successfully read from a property that <br>
I&#39;ll get the same thing out on subsequent reads and I consider this to =
<br>
be valuable and strongly disagree on the &quot;most poorly designed feature=
&quot; bit.<br>
<br>
Yes, I understand that __get() currently is an exception to that <br>
guarantee, but that does not mean that further exceptions should be <br>
added to water down readonly into something that is completely useless.<br>
<br>
&gt; 2. In 8.4, if a class is marked `readonly`, you basically forbid it fr=
om having any hooks of any kind, even though you absolutely can honor the w=
rite-once-ness of the properties while still having hooks.=C2=A0 And that a=
pplies to child classes, too, because `readonly`-ness inherits.=C2=A0 So ad=
ding a single hook means you have to move the readonly to all the other pro=
perties individually, which if inheritance is involved you cannot do.<br>
&gt; <br>
&gt; The RFC aims to address point 2 in a way that still respects point 1, =
but only point 1 as it actually is (write-once), not as we wish it to be (i=
mmutability).<br>
<br>
Readonly is immutability of values (or in other words immutability of <br>
identity). For objects this means immutability of the object handle, for <b=
r>
other types this means actual immutability.<br>
<br>
I also feel compelled to mention at this point that the commonly <br>
repeated statement of &quot;Objects are passed by reference&quot; is incorr=
ect. <br>
It&#39;s that &quot;the object handle is passed by value&quot;. And then it=
&#39;s fully <br>
consistent with how readonly works as of now.<br>
<br>
&gt; * set hooks for validation, which don&#39;t impact writeonce-ness.=C2=
=A0 I think everyone seems on board with that.<br>
<br>
Yes, allowing set hooks for readonly properties seems sound to me.<br>
<br>
&gt; * Lazy computed properties.=C2=A0 I use these a ton, even for internal=
 caching purposes.=C2=A0 99% of the time I cache them because my objects ar=
e practically immutable, and $this-&gt;foo ??=3D whatever is an easy enough=
 pattern.=C2=A0 (If they&#39;re not cached then it would be a virtual prope=
rty, which we&#39;re not dealing with for now.)=C2=A0 As long as you&#39;re=
 caching it in that fashion, the write-once-ness still ends up respected.<b=
r>
&gt; <br>
&gt; Honestly, Nick tried to come up with examples yesterday while we were =
talking that would not fit into one of those two categories, and for every =
one of them my answer was &quot;if your code is already that badly designed=
, there&#39;s nothing we can do for you.&quot; :-)<br>
<br>
It&#39;s nice to hear that there are no other usecases for hooks on readonl=
y <br>
properties, since this means that we can just allow the &#39;set&#39; hook =
and <br>
add an &#39;init&#39; hook for the lazy computation use-case without needin=
g to <br>
violate the semantics of `readonly` by allowing a `get` hook.<br>
<br>
&gt; An init hook would be clearer, certainly, though it also has its own e=
dge cases.=C2=A0 Can you set something that has an init hook?=C2=A0 What ha=
ppens if there&#39;s both a get and init hook?=C2=A0 These probably have an=
swers that could be sorted out, but that&#39;s a different question from &q=
uot;why the &lt;censored&gt; does a readonly class forbid me using even rud=
imentary hooks???&quot;<br>
<br>
Not clearer. It would be the only thing that is semantically sound. <br>
While it certainly needs careful consideration of semantics to ensure <br>
there are no edge cases, figuring this out should be much easier than <br>
intentionally introducing edge cases via a get hook.<br>
<br>
As to your questions: The init hook is triggered when reading from a <br>
property that is in the uninitialized state. The return value of the <br>
hook is stored in the property and returned as the result of the read <br>
operation. Having an init hook implies the property is non-virtual.<br>
<br>
- Yes, you can set something that has an init hook. Setting means that <br>
the property will no longer be uninitialized, which means that the init <br=
>
hook will no longer be called.<br>
- If there is both a get and an init hook, the init hook will be called <br=
>
when the backing store is uninitialized. The result of the init hook <br>
will then also go through the get hook. On subsequent reads only the get <b=
r>
hook will be called.<br>
<br>
Best regards<br>
Tim D=C3=BCsterhus<br></blockquote></div></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">Hi Tim,</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">The problem with allowing only set hooks is t=
hat readonly class won&#39;t be compatible with hooks, I think that is one =
of the main motivations behind this RFC.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
=C2=A0=C2=A0</div><div dir=3D"auto">Faizan Akram Dar</div><div dir=3D"auto"=
><a href=3D"http://faizanakram.me">faizanakram.me</a></div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_contain=
er"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--00000000000030b056063a34e694--