Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128011
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 11 Jul 2025 13:57:47 +0200
To: Nick <php@nicksdot.dev>
Cc: internals@lists.php.net
Message-ID: <8ac21ca5-4a7b-47f1-aa75-5ce5bb0301d9@app.fastmail.com>
In-Reply-To: <B095A0D4-5CF2-451A-A4AB-495E230EFB23@nicksdot.dev>
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>
 <6acab95a554fe5e188364840ea36d2b7@bastelstu.be>
 <cd86dc08-9aa8-4820-b367-fbd823db92e7@app.fastmail.com>
 <baf8950f-1212-4d83-aac4-7333aaa058d6@app.fastmail.com>
 <B095A0D4-5CF2-451A-A4AB-495E230EFB23@nicksdot.dev>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
Content-Type: multipart/alternative;
 boundary=3209718a4c3c4143abf2ff13c73e62b6
From: rob@bottled.codes ("Rob Landers")

--3209718a4c3c4143abf2ff13c73e62b6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Jul 11, 2025, at 13:40, Nick wrote:
>=20
>> On 11. Jul 2025, at 01:43, Rob Landers <rob@bottled.codes> wrote:
>>=20
>> On Thu, Jul 10, 2025, at 17:34, Larry Garfield wrote:
>>> On Thu, Jul 10, 2025, at 5:43 AM, Tim D=C3=BCsterhus wrote:
>>> > Hi
>>> >
>>> > Am 2025-07-08 17:32, schrieb Nicolas Grekas:
>>> >> I also read Tim's argument that new features could be stricter. I=
f one
>>> >> wants to be stricter and forbid extra behaviors that could be add=
ed 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.
>>> >
>>> > Making the class final still would not allow to optimize based on =
the=20
>>> > fact that the identity of a value stored in a readonly property wi=
ll not=20
>>> > change after successfully reading from the property once. Whether =
or not=20
>>> > a property hooked must be considered an implementation detail, sin=
ce a=20
>>> > main point of the property hooks RFC was that hooks can be added a=
nd=20
>>> > removed without breaking compatibility for the user of the API.
>>> >
>>> >> engine-assisted strictness in this case. You cannot write such co=
de in=20
>>> >> a
>>> >> non-readonly way by mistake, so it has to be by intent.
>>> >
>>> > That is saying "it's impossible to introduce bugs".
>>> >
>>> >> PS: as I keep repeating, readonly doesn't immutable at all. I kno=
w this=20
>>> >> is
>>> >> written as such in the original RFC, but the concrete definition =
and
>>> >> implementation of readonly isn't: you can set mutable objects to=20
>>> >> readonly
>>> >> properties, and that means even readonly classes/properties are=20
>>> >> mutable, in
>>> >> the generic case.
>>> >
>>> > `readonly` guarantees the immutability of identity. While you can=20
>>> > certainly mutate mutable objects, the identity of the stored objec=
t=20
>>> > doesn't change.
>>> >
>>> > Best regards
>>> > Tim D=C3=BCsterhus
>>>=20
>>> Nick previously suggested having the get-hook's first return value c=
ached; it would still be subsequently called, so any side effects would =
still happen (though I don't know why you'd want side effects), but only=
 the first returned value would ever get returned.  Would anyone find th=
at acceptable?  (In the typical case, it would be the same as the curren=
t $this->foo ??=3D compute() pattern, just with an extra cache entry.)
>>>=20
>>> --Larry Garfield
>>>=20
>>=20
>> I think that only covers one use-case for getters on readonly classes=
. Take this example for discussion:
>>=20
>> readonly class User {
>>     public int $elapsedTimeSinceCreation { get =3D> time() - $this->c=
reatedAt; }
>>     private int $cachedResult;
>>     public int $totalBalance { get =3D> $this->cachedResult ??=3D 5+1=
0; }
>>     public int $accessLevel { get =3D> getCurrentAccessLevel(); }
>>     public function __construct(public int $createdAt) {}
>> }
>>=20
>> $user =3D new User(time() - 5);
>> var_dump($user->elapsedTimeSinceCreation); // 5
>> var_dump($user->totalBalance); // 15
>> var_dump($user->accessLevel); // 42
>>=20
>> In this example, we have three of the most common ones:
>>  1. Computed Properties (elapsedTimeSinceCreation): these are propert=
ies of the object that are relevant to the object in question, but are n=
ot static. In this case, you are not writing to the object. It is still =
"readonly".
>>  2. Memoization (expensiveCalculation): only calculate the property o=
nce and only once. This is a performance optimization. It is still "read=
only".
>>  3. External State (accessLevel): properties of the object that rely =
on some external state, which due to architecture or other convienence m=
ay not make sense as part of object construction. It is still "readonly".
>> You can mix-and-match these to provide your own level of immutability=
, but memoization is certainly not the only one.=20
>>=20
>> You could make the argument that these should be functions, but I'd p=
osit that these are properties of the user object. In other words, a fun=
ction to get these values would probably be named `getElapsedTimeSinceCr=
eation()`, `getTotalBalance`, or `getAccessLevel` -- we'd be writing get=
ters anyway.
>>=20
>> =E2=80=94 Rob
> Hey Rob,
>=20
> We ended up where we are now because more people than not voiced that =
they would expect a `readonly` property value to never change after `get=
` was first called.
> As you can see in my earlier mails I also was of a different opinion. =
I asked "what if a user wants exactly that=E2=80=9D?=20
> You brought good examples for when =E2=80=9Cthat" could be the case.
> =20
> It is correct, with the current alternative implementations your examp=
les would be cached.
> A later call to the property would *not* use the updated time or a pot=
entially updated external state.
>=20
> After thinking a lot about it over the last days I think that makes se=
nse.=20
>=20
> To stick to your usage of `time()`, I think the following is a good ex=
ample:
>=20
> ```php
> readonly class JobHelper
> {
>     public function __construct(
>         public readonly string $uniqueRunnerKey {
>             get =3D> 'runner/' . date("Ymd_H-i-s", time()) . '_' . (st=
ring) random_int(1, 100) . '/'. $this->uniqueRunnerKey;
>         }
>     ) {}
> }
>=20
> $helper =3D new JobHelper('report.txt=E2=80=99);
> $key1 =3D $helper->uniqueRunnerKey;
> sleep(2);
> $key2 =3D $helper->uniqueRunnerKey;
> var_dump($key1 =3D=3D=3D $key2); // true
> ```
>=20
> It has two dynamic path elements, to achieve some kind of randomness. =
As a user you still can expect $key1 =3D=3D=3D $key2 to hold when using =
`readonly`.
>=20
> Claude's argument is strong, because we also cannot write twice to a `=
readonly` property.
> So it=E2=80=99s fair to say reading should also be predictable, and re=
turn the exact same value on consecutive calls.
>=20
> If users don=E2=80=99t want that, they can opt-out by not using `reado=
nly`. The guarantee only holds in combination with `readonly`.
> Alternatively, as you proposed, using methods (which I think would rea=
lly be a better fit; alternatively virtual properties which also will no=
t support `readonly`.
>=20
> With what we have now, both =E2=80=9Ccamps" will be able to achieve wh=
at they want transparently.
> And I believe that=E2=80=99s a good middle ground we should go forward=
 with.
>=20
> *Cheers,*
> Nick

Hey Nick,

After sleeping on it, I think I agree with this assessment. For backed p=
roperties, especially, it makes sense that the value feels "immutable". =
If and when we get to virtual properties, maybe not. But that's a bridge=
 to cross later.

=E2=80=94 Rob
--3209718a4c3c4143abf2ff13c73e62b6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Fri, Jul 11, 2025, at 13:40, Nick wrote:</div><bloc=
kquote type=3D"cite" id=3D"qt" style=3D"overflow-wrap:break-word;"><div>=
<br></div><div><blockquote type=3D"cite"><div>On 11. Jul 2025, at 01:43,=
 Rob Landers &lt;rob@bottled.codes&gt; wrote:</div><div><div><div><br></=
div><div>On Thu, Jul 10, 2025, at 17:34, Larry Garfield wrote:</div><blo=
ckquote type=3D"cite" id=3D"qt-qt" style=3D""><div>On Thu, Jul 10, 2025,=
 at 5:43 AM, Tim D=C3=BCsterhus wrote:</div><div>&gt; Hi</div><div>&gt;<=
/div><div>&gt; Am 2025-07-08 17:32, schrieb Nicolas Grekas:</div><div>&g=
t;&gt; I also read Tim's argument that new features could be stricter. I=
f one</div><div>&gt;&gt; wants to be stricter and forbid extra behaviors=
 that could be added by</div><div>&gt;&gt; either the proposed hooks or =
__get, then the answer is : make the class</div><div>&gt;&gt; final. Thi=
s is the only real way to enforce readonly-ness in PHP.</div><div>&gt;</=
div><div>&gt; Making the class final still would not allow to optimize b=
ased on the&nbsp;</div><div>&gt; fact that the identity of a value store=
d in a readonly property will not&nbsp;</div><div>&gt; change after succ=
essfully reading from the property once. Whether or not&nbsp;</div><div>=
&gt; a property hooked must be considered an implementation detail, sinc=
e a&nbsp;</div><div>&gt; main point of the property hooks RFC was that h=
ooks can be added and&nbsp;</div><div>&gt; removed without breaking comp=
atibility for the user of the API.</div><div>&gt;</div><div>&gt;&gt; eng=
ine-assisted strictness in this case. You cannot write such code in&nbsp=
;</div><div>&gt;&gt; a</div><div>&gt;&gt; non-readonly way by mistake, s=
o it has to be by intent.</div><div>&gt;</div><div>&gt; That is saying "=
it's impossible to introduce bugs".</div><div>&gt;</div><div>&gt;&gt; PS=
: as I keep repeating, readonly doesn't immutable at all. I know this&nb=
sp;</div><div>&gt;&gt; is</div><div>&gt;&gt; written as such in the orig=
inal RFC, but the concrete definition and</div><div>&gt;&gt; implementat=
ion of readonly isn't: you can set mutable objects to&nbsp;</div><div>&g=
t;&gt; readonly</div><div>&gt;&gt; properties, and that means even reado=
nly classes/properties are&nbsp;</div><div>&gt;&gt; mutable, in</div><di=
v>&gt;&gt; the generic case.</div><div>&gt;</div><div>&gt; `readonly` gu=
arantees the immutability of identity. While you can&nbsp;</div><div>&gt=
; certainly mutate mutable objects, the identity of the stored object&nb=
sp;</div><div>&gt; doesn't change.</div><div>&gt;</div><div>&gt; Best re=
gards</div><div>&gt; Tim D=C3=BCsterhus</div><div><br></div><div>Nick pr=
eviously suggested having the get-hook's first return value cached; it w=
ould still be subsequently called, so any side effects would still happe=
n (though I don't know why you'd want side effects), but only the first =
returned value would ever get returned.&nbsp; Would anyone find that acc=
eptable?&nbsp; (In the typical case, it would be the same as the current=
 $this-&gt;foo ??=3D compute() pattern, just with an extra cache entry.)=
</div><div><br></div><div>--Larry Garfield</div><div><br></div></blockqu=
ote><div><br></div><div>I think that only covers one use-case for getter=
s on readonly classes. Take this example for discussion:</div><div><br><=
/div><div>readonly class User {</div><div>&nbsp;&nbsp;&nbsp; public int =
$elapsedTimeSinceCreation { get =3D&gt; time() - $this-&gt;createdAt; }<=
/div><div>&nbsp;&nbsp;&nbsp; private int $cachedResult;</div><div>&nbsp;=
&nbsp;&nbsp; public int $totalBalance { get =3D&gt; $this-&gt;cachedResu=
lt ??=3D 5+10; }</div><div>&nbsp;&nbsp;&nbsp; public int $accessLevel { =
get =3D&gt; getCurrentAccessLevel(); }</div><div>&nbsp;&nbsp;&nbsp; publ=
ic function __construct(public int $createdAt) {}</div><div>}</div><div>=
<br></div><div>$user =3D new User(time() - 5);</div><div>var_dump($user-=
&gt;elapsedTimeSinceCreation); // 5</div><div>var_dump($user-&gt;totalBa=
lance); // 15</div><div>var_dump($user-&gt;accessLevel); // 42</div><div=
><br></div><div>In this example, we have three of the most common ones:<=
/div><ol><li>Computed Properties (elapsedTimeSinceCreation): these are p=
roperties of the object that are relevant to the object in question, but=
 are not static. In this case, you are not writing to the object. It is =
still "readonly".</li><li>Memoization (expensiveCalculation): only calcu=
late the property once and only once. This is a performance optimization=
. It is still "readonly".</li><li>External State (accessLevel): properti=
es of the object that rely on some external state, which due to architec=
ture or other convienence may not make sense as part of object construct=
ion. It is still "readonly".</li></ol><div>You can mix-and-match these t=
o provide your own level of immutability, but memoization is certainly n=
ot the only one.&nbsp;</div><div><br></div><div>You could make the argum=
ent that these should be functions, but I'd posit that these are propert=
ies of the user object. In other words, a function to get these values w=
ould probably be named `getElapsedTimeSinceCreation()`, `getTotalBalance=
`, or `getAccessLevel` -- we'd be writing getters anyway.</div><div><br>=
</div><div id=3D"qt-sig121229152">=E2=80=94 Rob</div></div></div></block=
quote></div><div>Hey Rob,</div><div><br></div><div>We ended up where we =
are now because more people than not voiced that they would expect a `re=
adonly` property value to never change after `get` was first called.</di=
v><div>As you can see in my earlier mails I also was of a different opin=
ion. I asked "what if a user wants exactly that=E2=80=9D?&nbsp;</div><di=
v>You brought good examples for when =E2=80=9Cthat" could be the case.</=
div><div>&nbsp;</div><div>It is correct, with the current alternative im=
plementations your examples would be cached.</div><div>A later call to t=
he property would *not* use the updated time or a potentially updated ex=
ternal state.</div><div><br></div><div>After thinking a lot about it ove=
r the last days I think that makes sense.&nbsp;</div><div><br></div><div=
>To stick to your usage of `time()`, I think the following is a good exa=
mple:</div><div><br></div><div>```php</div><div><div style=3D"background=
-color:rgb(255, 255, 255);"><pre style=3D"font-family:&quot;JetBrains Mo=
no&quot;, monospace;font-size:12pt;"><div><span style=3D"color:rgb(215, =
58, 73);">readonly class </span><span style=3D"color:rgb(227, 98, 9);">J=
obHelper<br></span>{</div><div>    <span style=3D"color:rgb(215, 58, 73)=
;">public function </span><span style=3D"color:rgb(111, 66, 193);">__con=
struct</span>(</div><div>        <span style=3D"color:rgb(215, 58, 73);"=
>public readonly string </span>$uniqueRunnerKey {</div><div>            =
get <span style=3D"color:rgb(179, 29, 40);">=3D</span>&gt; 'runner/' . <=
span style=3D"color:rgb(0, 92, 197);">date</span>("Ymd_H-i-s", time()) .=
 '_' . (string) random_int(1, 100) . '/'. $this-&gt;uniqueRunnerKey;</di=
v><div>        }</div><div>    ) {}</div><div>}</div><div><br></div><div=
>$helper <span style=3D"color:rgb(179, 29, 40);">=3D </span><span style=3D=
"color:rgb(215, 58, 73);">new </span>JobHelper('report.txt=E2=80=99);</d=
iv></pre><pre style=3D"font-family:&quot;JetBrains Mono&quot;, monospace=
;font-size:12pt;"><div>$key1 <span style=3D"color:rgb(179, 29, 40);">=3D=
 </span>$helper<span style=3D"color:rgb(179, 29, 40);">-&gt;</span>uniqu=
eRunnerKey;</div><div><span style=3D"color:rgb(111, 66, 193);">sleep</sp=
an>(<span style=3D"color:rgb(0, 92, 197);">2</span>);</div><div>$key2 <s=
pan style=3D"color:rgb(179, 29, 40);">=3D </span>$helper<span style=3D"c=
olor:rgb(179, 29, 40);">-&gt;</span>uniqueRunnerKey;</div><div><span sty=
le=3D"color:rgb(111, 66, 193);">var_dump</span>($key1 <span style=3D"col=
or:rgb(179, 29, 40);">=3D=3D=3D </span>$key2); <span style=3D"color:rgb(=
150, 152, 150);">// true</span></div></pre></div></div><div>```</div><di=
v><br></div><div>It has two dynamic path elements, to achieve some kind =
of randomness. As a user you still can expect $key1 =3D=3D=3D $key2 to h=
old when using `readonly`.</div><div><br></div><div>Claude's argument is=
 strong, because we also cannot write twice to a `readonly` property.</d=
iv><div>So it=E2=80=99s fair to say reading should also be predictable, =
and return the exact same value on consecutive calls.</div><div><div><br=
></div><div>If users don=E2=80=99t want that, they can opt-out by not us=
ing `readonly`. The guarantee only holds in combination with `readonly`.=
</div><div>Alternatively, as you proposed, using methods (which I think =
would really be a better fit; alternatively virtual properties which als=
o will not support `readonly`.</div></div><div><br></div><div>With what =
we have now, both =E2=80=9Ccamps" will be able to achieve what they want=
 transparently.</div><div>And I believe that=E2=80=99s a good middle gro=
und we should go forward with.</div><div><br></div><div><b>Cheers,</b></=
div><div>Nick</div></blockquote><div><br></div><div>Hey Nick,</div><div>=
<br></div><div>After sleeping on it, I think I agree with this assessmen=
t. For backed properties, especially, it makes sense that the value feel=
s "immutable". If and when we get to virtual properties, maybe not. But =
that's a bridge to cross later.</div><div><br></div><div id=3D"sig121229=
152">=E2=80=94 Rob</div></body></html>
--3209718a4c3c4143abf2ff13c73e62b6--