Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128132
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 19 Jul 2025 09:46:14 +0200
To: "Claude Pache" <claude.pache@gmail.com>
Cc: erictnorris@gmail.com, "Nicolas Grekas" <nicolas.grekas+php@gmail.com>,
 "Larry Garfield" <larry@garfieldtech.com>,
 =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 "php internals" <internals@lists.php.net>
Message-ID: <247034b6-04cf-4f3e-a145-a30171af8c12@app.fastmail.com>
In-Reply-To: <77128196-8D53-40D6-9BB7-77160AD71ED9@gmail.com>
References: <378cd8b0-c4a8-4e53-b0bd-e9e4f30a454d@app.fastmail.com>
 <77128196-8D53-40D6-9BB7-77160AD71ED9@gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] Readonly property hooks
Content-Type: multipart/alternative;
 boundary=3312265fb50a43a4a2fa5360eff95da9
From: rob@bottled.codes ("Rob Landers")

--3312265fb50a43a4a2fa5360eff95da9
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sat, Jul 19, 2025, at 03:04, Claude Pache wrote:
>=20
>=20
>=20
>> Le 19 juil. 2025 =C3=A0 00:41, Rob Landers <rob@bottled.codes> a =C3=A9=
crit :
>>=20
>> The original author (Nikita) suggested that there's nothing in the or=
iginal design that precludes accessors -- and highlights languages where=
 there are both and they are doing just fine more than 5 years later.
>>=20
>=20
> Hi Rob,
>=20
> It is indeed entirely reasonable to have both readonly properties and =
hooked properties (aka accessors), and today PHP has indeed both of them=
 (and even asymmetric visibility on top of that, as a separate feature c=
ontrarily to C#). But it doesn=E2=80=99t mean that it is reasonable for =
the *same* property to be *both* readonly and hooked, which is the point=
 that is currently disputed. =E2=80=94 What do the other languages allow=
? Is it possible to define a readonly property with a user-defined gette=
r? (Disclaimer: Even if one of them allows such a thing, I=E2=80=99ll st=
ill think that it is a bad idea.)
>=20
> =E2=80=94Claude=20

Hey Claude,

From what I've seen in other languages, this combination is fairly commo=
n and not inherently poblematic.

- C# allows get hooks with user-defined logic, even in readonly structs.
- Kotlin uses val with a get() body, which is readonly from the consumer=
's perspective, even though the value is computed.
- TypeScript allows a get-only accessor which acts readonly.
- Swift also allows get-only computed accessors/hooks.

Most languages treat these as an abstraction boundary: allowing you to e=
xpose computed state while still guaranteeing external immutability.

This RFC is proposing something similar: the public surface is observabl=
y immutable, even if a value is derived. We can already do this today wi=
th more boilerplate:

class Foo {
  public function __construct(private readonly int $_bar) {}
  public int $bar { get =3D> $this->_bar * 2; }
}

The RFC reduces that boilerplate and clarifies intent. In the example ab=
ove, there is nothing mutable about it. It is "read only" from a public =
contract point-of-view, we just can't mark it as a readonly class.

As for side-effects or non-determinism, that is a valid concern, but one=
 that applies to any property hook and non-scalar property. A readonly d=
eclaration doesn't necessarily encourage or prevent that, it simply decl=
ares that the instance state cannot be mutated after construction.

I'd argue the RFC aligns well with the conventions and capabilities of o=
ther languages, and builds on what PHP already allows.

=E2=80=94 Rob
--3312265fb50a43a4a2fa5360eff95da9
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 Sat, Jul 19, 2025, at 03:04, Claude Pache wrote:</d=
iv><blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div =
dir=3D"ltr"><br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><div><=
br></div><blockquote type=3D"cite"><div>Le 19 juil. 2025 =C3=A0 00:41, R=
ob Landers &lt;rob@bottled.codes&gt; a =C3=A9crit&nbsp;:</div></blockquo=
te></div><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"qt-ali=
gn-start" style=3D"text-align:start;"><br></div><div class=3D"qt-align-s=
tart" style=3D"text-align:start;">The original author (Nikita) suggested=
 that there's nothing in the original design that precludes accessors --=
 and highlights languages where there are both and they are doing just f=
ine more than 5 years later.</div><div class=3D"qt-align-start" style=3D=
"text-align:start;"><br></div></div></blockquote><div><br></div><div>Hi =
Rob,</div><div><br></div><div>It is indeed entirely reasonable to have b=
oth readonly properties and hooked properties (aka accessors), and today=
 PHP has indeed both of them (and even asymmetric visibility on top of t=
hat, as a separate feature contrarily to C#). But it doesn=E2=80=99t mea=
n that it is reasonable for the *same* property to be *both* readonly an=
d hooked, which is the point that is currently disputed. =E2=80=94 What =
do the other languages allow? Is it possible to define a readonly proper=
ty with a user-defined getter? (Disclaimer: Even if one of them allows s=
uch a thing, I=E2=80=99ll still think that it is a bad idea.)</div><div>=
<br></div><div>=E2=80=94Claude&nbsp;</div></div></blockquote><div><br></=
div><div>Hey Claude,</div><div><br></div><div>From what I've seen in oth=
er languages, this combination is fairly common and not&nbsp;inherently =
poblematic.</div><div><br></div><div>- C# allows get hooks with user-def=
ined logic, even in readonly structs.</div><div>- Kotlin uses val with a=
 get() body, which is readonly from the consumer's perspective, even tho=
ugh the value is computed.</div><div>- TypeScript allows a get-only acce=
ssor which acts readonly.</div><div>- Swift also allows get-only compute=
d accessors/hooks.</div><div><br></div><div>Most languages treat these a=
s an abstraction boundary: allowing you to expose computed state while s=
till guaranteeing external immutability.</div><div><br></div><div>This R=
FC is proposing something similar: the public surface is observably immu=
table, even if a value is derived. We can already do this today with mor=
e boilerplate:<br></div><div><br></div><div>class Foo {</div><div>&nbsp;=
 public function __construct(private readonly int $_bar) {}</div><div>&n=
bsp; public int $bar { get =3D&gt; $this-&gt;_bar * 2; }</div><div>}</di=
v><div><br></div><div>The RFC reduces that boilerplate and clarifies int=
ent. In the example above, there is nothing mutable about it. It is "rea=
d only" from a public contract point-of-view, we just can't mark it as a=
 readonly class.</div><div><br></div><div>As for side-effects or non-det=
erminism, that is a valid concern, but one that applies to any property =
hook and non-scalar property. A readonly declaration doesn't necessarily=
 encourage or prevent that, it simply declares that the instance state c=
annot be mutated after construction.</div><div><br></div><div>I'd argue =
the RFC aligns well with the conventions and capabilities of other langu=
ages, and builds on what PHP already allows.</div><div><br></div><div id=
=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--3312265fb50a43a4a2fa5360eff95da9--