Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128122
Precedence: bulk
MIME-Version: 1.0
References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com>
 <09780759-9ddc-45e2-9376-befb8e378775@app.fastmail.com> <0e8eb146-3b1d-4fc2-ad83-77062f2063c9@bastelstu.be>
In-Reply-To: <0e8eb146-3b1d-4fc2-ad83-77062f2063c9@bastelstu.be>
Date: Fri, 18 Jul 2025 19:10:19 +0200
Message-ID: <CAOWwgpmw7jcvebZKxfN0y9zXuncW4OA4SxCrWGUjyWB-1HTWuA@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [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="0000000000001e0d85063a37347e"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000001e0d85063a37347e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le ven. 18 juil. 2025 =C3=A0 18:32, Tim D=C3=BCsterhus <tim@bastelstu.be> a=
 =C3=A9crit :

> Hi
>
> On 7/17/25 18:26, Larry Garfield wrote:
> > Given the lack of consensus both here and in off-list discussions on ho=
w
> to handle get hooks, we have done the following:
> >
> > * Split the RFC into two sections, one for get, one for set.
> > * Expanded and refined the examples for both. The implementation is
> still the original, however.
> > * Split the vote into two: one for allowing readonly get hooks, one for
> readonly set hooks.
> >
> > We will start the vote sometime this weekend, most likely, unless some
> major feedback appears before then, and let the chips fall where they may=
.
>
> After working through (most of) the discussion, I've now taken a look at
> the updated RFC. I have the following remarks:
>
> 1.
>
> > It is really =E2=80=9Cwrite-once=E2=80=9D, which is not the same as imm=
utable (as shown
> above). But there's no reason that =E2=80=9Cwrite-once=E2=80=9D need be i=
ncompatible with
> hooks.
>
> This is a strawman argumentation, as I've outlined in my previous
> emails, calling readonly "write-once" is wrong. It is a reasonable user
> expectation to always get the identical value when reading a value that
> may only be set once. By calling it "write-once" you are trying to shift
> the focus to the write operation, which is totally irrelevant for user
> expectations when interacting with readonly properties. Especially for
> expectations of users that just *use* a class rather than writing one.
>

To my ears, write-once is more accurate than readonly because it sticks to
the facts of how this behaves. That's very relevant.
Using readonly to suggest immutable is where the arguments for rejecting
this RFC are weak.
readonly doesn't mean immutable, no matter how hard some want it to be...


>
> 2.
>
> > The concern would only appear if someone is deliberately doing somethin=
g
> non-stable
>
> Or if someone accidentally calls a (deep) function chain that is non-pure=
.
>
> 3.
>
> > Or, for a more real-world and larger example, PHP 8.4 requires this:
>
> This is false. You are perfectly able to write this in PHP 8.4:
>
>      final readonly class Entry
>      {
>          public readonly $terms;
>
>          public function __construct(
>              public string $word,
>              public string $slug,
>              array $terms,
>          ) {
>              $this->terms =3D $this->upcastTerms($terms);
>          }
>
>          private function upcastTerms(array $terms): array
>          {
>              $upcast =3D static fn (Term|array $term): Term
>                  =3D> $term instanceof Term ? $term : new Term(...$term);
>              return array_map($upcast, $value)
>          }
>      }
>
> In no way do you need to use a property hook.
>
> 4.
>
> > // New code in 8.5:
> >
> > $p =3D new PositivePoint(3, 4);
> > $p2 =3D clone($p, ['x' =3D> -10]);
>
> This is not legal code in PHP 8.5. Clone-with respects visibility and
> since your asymmetric visibility RFC included the change, you are
> probably aware that `readonly` implies `protected(set)`.

5.
>
> > but are now necessary to ensure that invariants are enforced.
>
> And therefore with PHP 8.5 hooks are not necessary to enforce
> invariants, except in the rare case where a `public(set) readonly`
> property is used.
>

Of course it's rare. It's brand new...
Yet this example comes back many times.
This is how the community would like to use clone-with.
This should be acknowledged.

The fact that protected(set) is (currently) the default is not an argument
to make public(set) a second class citizen.



> 6.
>
> > So no guarantees are softened by this RFC.
>
> Yes, they are. Unless `__get()` is implemented on a class (which is
> explicitly visible as part of the public API), readonly guarantees the
> immutability of identity.
>

Which is not really relevant when talking about immutability.
What everybody is looking for when using that word is immutable objects.


7.
>
> > While that is an interesting idea that has been floated a few times, it
> has enough complexities and edge cases of its own to address that we feel
> it is out of scope.
>
> While it certainly is your right as the RFC authors to consider certain
> things out of scope for an RFC, I strongly oppose the notion of shipping
> something that is strictly inferior and comes with obvious semantic
> issues due to perceived complexity of another solution and then
> following up with the proper solution that has already been identified.
> As I've outlined in my previous emails, I found defining semantics for
> an 'init' hook straight-forward when looking at how PHP works as of today=
.
>
> 8.
>
> > However, this RFC is in no way incompatible with adding an init hook in
> the future should it be proposed.
>
> This is true, but as I've mentioned before, an 'init' hook would enable
> the same use cases without bringing along issues. So it really should be
> "one of them, but not both" (with "one of them" being the init hook).
>
> --------
>
> After reading through the discussion, it seems the only argument against
> the 'init' hook is perceived complexity. It is not at all clear to me
> why this means that we must now rush something with clear issues into
> PHP 8.5.
>

I'd understand the arguments you're pushing for if readonly were
appropriate to build immutable objects. Yet that's not the case, so such
reasoning is built on sand I'm sorry...

To me the RFC enables useful capabilities that authors are going to need.
Or find workarounds for. Which means more ugliness to come...

Nicolas

--0000000000001e0d85063a37347e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 18 juil=
. 2025 =C3=A0=C2=A018:32, Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bast=
elstu.be" target=3D"_blank">tim@bastelstu.be</a>&gt; a =C3=A9crit=C2=A0:<br=
></div><blockquote 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>
On 7/17/25 18:26, Larry Garfield wrote:<br>
&gt; Given the lack of consensus both here and in off-list discussions on h=
ow to handle get hooks, we have done the following:<br>
&gt; <br>
&gt; * Split the RFC into two sections, one for get, one for set.<br>
&gt; * Expanded and refined the examples for both. The implementation is st=
ill the original, however.<br>
&gt; * Split the vote into two: one for allowing readonly get hooks, one fo=
r readonly set hooks.<br>
&gt; <br>
&gt; We will start the vote sometime this weekend, most likely, unless some=
 major feedback appears before then, and let the chips fall where they may.=
<br>
<br>
After working through (most of) the discussion, I&#39;ve now taken a look a=
t <br>
the updated RFC. I have the following remarks:<br>
<br>
1.<br>
<br>
&gt; It is really =E2=80=9Cwrite-once=E2=80=9D, which is not the same as im=
mutable (as shown above). But there&#39;s no reason that =E2=80=9Cwrite-onc=
e=E2=80=9D need be incompatible with hooks.<br>
<br>
This is a strawman argumentation, as I&#39;ve outlined in my previous <br>
emails, calling readonly &quot;write-once&quot; is wrong. It is a reasonabl=
e user <br>
expectation to always get the identical value when reading a value that <br=
>
may only be set once. By calling it &quot;write-once&quot; you are trying t=
o shift <br>
the focus to the write operation, which is totally irrelevant for user <br>
expectations when interacting with readonly properties. Especially for <br>
expectations of users that just *use* a class rather than writing one.<br><=
/blockquote><div><br></div><div>To my ears, write-once is more accurate tha=
n readonly=C2=A0because it sticks to the facts of how this behaves. That=
9;s very relevant.</div><div>Using readonly to suggest immutable is where t=
he arguments for rejecting this RFC are weak.</div><div>readonly doesn&#39;=
t mean=C2=A0immutable, no=C2=A0matter how hard some want it to be...</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2.<br>
<br>
&gt; The concern would only appear if someone is deliberately doing somethi=
ng non-stable<br>
<br>
Or if someone accidentally calls a (deep) function chain that is non-pure.<=
br>
<br>
3.<br>
<br>
&gt; Or, for a more real-world and larger example, PHP 8.4 requires this:<b=
r>
<br>
This is false. You are perfectly able to write this in PHP 8.4:<br>
<br>
=C2=A0 =C2=A0 =C2=A0final readonly class Entry<br>
=C2=A0 =C2=A0 =C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public readonly $terms;<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public function __construct(<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string $word,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string $slug,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0array $terms,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this-&gt;terms =3D $this-&=
gt;upcastTerms($terms);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0private function upcastTerms(array $terms=
): array<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$upcast =3D static fn (Term=
|array $term): Term<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D&gt; $term=
 instanceof Term ? $term : new Term(...$term);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return array_map($upcast, $=
value)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0}<br>
<br>
In no way do you need to use a property hook.<br>
<br>
4.<br>
<br>
&gt; // New code in 8.5:<br>
&gt;=C2=A0 <br>
&gt; $p =3D new PositivePoint(3, 4);<br>
&gt; $p2 =3D clone($p, [&#39;x&#39; =3D&gt; -10]);<br>
<br>
This is not legal code in PHP 8.5. Clone-with respects visibility and <br>
since your asymmetric visibility RFC included the change, you are <br>
probably aware that `readonly` implies `protected(set)`.=C2=A0</blockquote>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">

5.<br>
<br>
&gt; but are now necessary to ensure that invariants are enforced.<br>
<br>
And therefore with PHP 8.5 hooks are not necessary to enforce <br>
invariants, except in the rare case where a `public(set) readonly` <br>
property is used.<br></blockquote><div><br></div><div><div>Of course it&#39=
;s rare. It&#39;s brand new...</div><div>Yet this example comes back many t=
imes.</div><div>This is how the community would like to use clone-with.</di=
v><div>This should be acknowledged.</div><div><br></div><div>The fact that =
protected(set) is (currently) the default is not an argument to make public=
(set) a second class citizen.</div></div><div><br></div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
6.<br>
<br>
&gt; So no guarantees are softened by this RFC.<br>
<br>
Yes, they are. Unless `__get()` is implemented on a class (which is <br>
explicitly visible as part of the public API), readonly guarantees the <br>
immutability of identity.<br></blockquote><div><br></div><div></div><div>Wh=
ich is not really relevant when talking about immutability.</div><div>What =
everybody is looking=C2=A0for when using that word is immutable objects.</d=
iv><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">

7.<br>
<br>
&gt; While that is an interesting idea that has been floated a few times, i=
t has enough complexities and edge cases of its own to address that we feel=
 it is out of scope.<br>
<br>
While it certainly is your right as the RFC authors to consider certain <br=
>
things out of scope for an RFC, I strongly oppose the notion of shipping <b=
r>
something that is strictly inferior and comes with obvious semantic <br>
issues due to perceived complexity of another solution and then <br>
following up with the proper solution that has already been identified. <br=
>
As I&#39;ve outlined in my previous emails, I found defining semantics for =
<br>
an &#39;init&#39; hook straight-forward when looking at how PHP works as of=
 today.<br>
<br>
8.<br>
<br>
&gt; However, this RFC is in no way incompatible with adding an init hook i=
n the future should it be proposed.<br>
<br>
This is true, but as I&#39;ve mentioned before, an &#39;init&#39; hook woul=
d enable <br>
the same use cases without bringing along issues. So it really should be <b=
r>
&quot;one of them, but not both&quot; (with &quot;one of them&quot; being t=
he init hook).<br>
<br>
--------<br>
<br>
After reading through the discussion, it seems the only argument against <b=
r>
the &#39;init&#39; hook is perceived complexity. It is not at all clear to =
me <br>
why this means that we must now rush something with clear issues into <br>
PHP 8.5.<br></blockquote><div><br></div><div>I&#39;d understand the argumen=
ts you&#39;re pushing for if readonly were appropriate to build immutable o=
bjects.=C2=A0Yet that&#39;s not the case, so such reasoning is built on san=
d I&#39;m sorry...</div><div><br></div><div>To me the RFC enables useful ca=
pabilities that authors are going to need. Or find workarounds for. Which m=
eans more ugliness to come...</div><div><br></div><div>Nicolas</div></div><=
/div>
</div>

--0000000000001e0d85063a37347e--