Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127998
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 10 Jul 2025 20:43:38 +0200
To: internals@lists.php.net
Message-ID: <baf8950f-1212-4d83-aac4-7333aaa058d6@app.fastmail.com>
In-Reply-To: <cd86dc08-9aa8-4820-b367-fbd823db92e7@app.fastmail.com>
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>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
Content-Type: multipart/alternative;
 boundary=8f7c50a40a6944edbdadb6fbb73b48c4
From: rob@bottled.codes ("Rob Landers")

--8f7c50a40a6944edbdadb6fbb73b48c4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



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. 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 c=
lass
> >> 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 th=
e=20
> > fact that the identity of a value stored in a readonly property will=
 not=20
> > change after successfully reading from the property once. Whether or=
 not=20
> > a property hooked must be considered an implementation detail, since=
 a=20
> > main point of the property hooks RFC was that hooks can be added and=20
> > removed without breaking compatibility for the user of the API.
> >
> >> engine-assisted strictness in this case. You cannot write such code=
 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 know =
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 object=20
> > doesn't change.
> >
> > Best regards
> > Tim D=C3=BCsterhus
>=20
> Nick previously suggested having the get-hook's first return value cac=
hed; it would still be subsequently called, so any side effects would st=
ill happen (though I don't know why you'd want side effects), but only t=
he first returned value would ever get returned.  Would anyone find that=
 acceptable?  (In the typical case, it would be the same as the current =
$this->foo ??=3D compute() pattern, just with an extra cache entry.)
>=20
> --Larry Garfield
>=20

I think that only covers one use-case for getters on readonly classes. T=
ake this example for discussion:

readonly class User {
    public int $elapsedTimeSinceCreation { get =3D> time() - $this->crea=
tedAt; }
    private int $cachedResult;
    public int $totalBalance { get =3D> $this->cachedResult ??=3D 5+10; }
    public int $accessLevel { get =3D> getCurrentAccessLevel(); }
    public function __construct(public int $createdAt) {}
}

$user =3D new User(time() - 5);
var_dump($user->elapsedTimeSinceCreation); // 5
var_dump($user->totalBalance); // 15
var_dump($user->accessLevel); // 42

In this example, we have three of the most common ones:
 1. Computed Properties (elapsedTimeSinceCreation): these are properties=
 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 "re=
adonly".
 2. Memoization (expensiveCalculation): only calculate the property once=
 and only once. This is a performance optimization. It is still "readonl=
y".
 3. External State (accessLevel): properties of the object that rely on =
some external state, which due to architecture or other convienence may =
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, b=
ut memoization is certainly not the only one.=20

You could make the argument that these should be functions, but I'd posi=
t that these are properties of the user object. In other words, a functi=
on to get these values would probably be named `getElapsedTimeSinceCreat=
ion()`, `getTotalBalance`, or `getAccessLevel` -- we'd be writing getter=
s anyway.

=E2=80=94 Rob
--8f7c50a40a6944edbdadb6fbb73b48c4
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 Thu, Jul 10, 2025, at 17:34, Larry Garfield wrote:<=
/div><blockquote type=3D"cite" id=3D"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>&gt;&gt; I also read Tim's argument that new features could be stric=
ter. If one</div><div>&gt;&gt; wants to be stricter and forbid extra beh=
aviors that could be added by</div><div>&gt;&gt; either the proposed hoo=
ks or __get, then the answer is : make the class</div><div>&gt;&gt; fina=
l. This 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 opti=
mize based on the&nbsp;</div><div>&gt; fact that the identity of a value=
 stored in a readonly property will not&nbsp;</div><div>&gt; change afte=
r successfully reading from the property once. Whether or not&nbsp;</div=
><div>&gt; a property hooked must be considered an implementation detail=
, since a&nbsp;</div><div>&gt; main point of the property hooks RFC was =
that hooks can be added and&nbsp;</div><div>&gt; removed without breakin=
g compatibility for the user of the API.</div><div>&gt;</div><div>&gt;&g=
t; engine-assisted strictness in this case. You cannot write such code i=
n&nbsp;</div><div>&gt;&gt; a</div><div>&gt;&gt; non-readonly way by mist=
ake, so it has to be by intent.</div><div>&gt;</div><div>&gt; That is sa=
ying "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 t=
his&nbsp;</div><div>&gt;&gt; is</div><div>&gt;&gt; written as such in th=
e original RFC, but the concrete definition and</div><div>&gt;&gt; imple=
mentation of readonly isn't: you can set mutable objects to&nbsp;</div><=
div>&gt;&gt; readonly</div><div>&gt;&gt; properties, and that means even=
 readonly classes/properties are&nbsp;</div><div>&gt;&gt; mutable, in</d=
iv><div>&gt;&gt; the generic case.</div><div>&gt;</div><div>&gt; `readon=
ly` guarantees the immutability of identity. While you can&nbsp;</div><d=
iv>&gt; certainly mutate mutable objects, the identity of the stored obj=
ect&nbsp;</div><div>&gt; doesn't change.</div><div>&gt;</div><div>&gt; B=
est regards</div><div>&gt; Tim D=C3=BCsterhus</div><div><br></div><div>N=
ick previously suggested having the get-hook's first return value cached=
; 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.&nbsp; Would anyone find th=
at acceptable?&nbsp; (In the typical case, it would be the same as the c=
urrent $this-&gt;foo ??=3D compute() pattern, just with an extra cache e=
ntry.)</div><div><br></div><div>--Larry Garfield</div><div><br></div></b=
lockquote><div><br></div><div>I think that only covers one use-case for =
getters on readonly classes. Take this example for discussion:</div><div=
><br></div><div>readonly class User {</div><div>&nbsp;&nbsp;&nbsp; publi=
c int $elapsedTimeSinceCreation { get =3D&gt; time() - $this-&gt;created=
At; }</div><div>&nbsp;&nbsp;&nbsp; private int $cachedResult;</div><div>=
&nbsp;&nbsp;&nbsp; public int $totalBalance { get =3D&gt; $this-&gt;cach=
edResult ??=3D 5+10; }</div><div>&nbsp;&nbsp;&nbsp; public int $accessLe=
vel { get =3D&gt; getCurrentAccessLevel(); }</div><div>&nbsp;&nbsp;&nbsp=
; public 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;t=
otalBalance); // 15</div><div>var_dump($user-&gt;accessLevel); // 42</di=
v><div><br></div><div>In this example, we have three of the most common =
ones:<br></div><ol><li>Computed Properties (elapsedTimeSinceCreation): t=
hese are properties of the object that are relevant to the object in que=
stion, but are not static. In this case, you are not writing to the obje=
ct. It is still "readonly".</li><li>Memoization (expensiveCalculation): =
only calculate the property once and only once. This is a performance op=
timization. It is still "readonly".</li><li>External State (accessLevel)=
: properties of the object that rely on some external state, which due t=
o architecture or other convienence may not make sense as part of object=
 construction. It is still "readonly".</li></ol><div>You can mix-and-mat=
ch these to provide your own level of immutability, but memoization is c=
ertainly not the only one.&nbsp;</div><div><br></div><div>You could make=
 the argument that these should be functions, but I'd posit that these a=
re properties of the user object. In other words, a function to get thes=
e values would probably be named `getElapsedTimeSinceCreation()`, `getTo=
talBalance`, or `getAccessLevel` -- we'd be writing getters anyway.</div=
><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></htm=
l>
--8f7c50a40a6944edbdadb6fbb73b48c4--