Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128119
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 18 Jul 2025 19:03:37 +0200
To: erictnorris@gmail.com
Cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 "Larry Garfield" <larry@garfieldtech.com>,
 "php internals" <internals@lists.php.net>
Message-ID: <625863a1-f9ec-481b-9227-d42e2300e1ca@app.fastmail.com>
In-Reply-To: 
 <CA+NMNO06L7J0sqRoBuX0Ts6jTbEF3BWC=qmYfHuN8yTDXrweDA@mail.gmail.com>
References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com>
 <9D5043B2-1589-4FD5-B289-6E98FB1177BE@nicksdot.dev>
 <CAPyj-LDVi3ZYQuzzJz7d+cHdU6C-cxYJUSkuzdyvWpw+sWuCsg@mail.gmail.com>
 <0856c89f-2000-448a-bbbf-c145a8699f6a@app.fastmail.com>
 <2641b8bc-6337-4b75-a5a3-93dee1b03796@bastelstu.be>
 <0d9a2968-26dd-43dd-9733-d2eb621ab9ec@app.fastmail.com>
 <CA+NMNO06L7J0sqRoBuX0Ts6jTbEF3BWC=qmYfHuN8yTDXrweDA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
Content-Type: multipart/alternative;
 boundary=2e4b967d7982479db0c6d86a87a44d7c
From: rob@bottled.codes ("Rob Landers")

--2e4b967d7982479db0c6d86a87a44d7c
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Jul 18, 2025, at 18:48, Eric Norris wrote:
> On Fri, Jul 18, 2025 at 12:01=E2=80=AFPM Rob Landers <rob@bottled.code=
s> wrote:
> >
> >
> >
> > On Fri, Jul 18, 2025, at 17:25, Tim D=C3=BCsterhus wrote:
> >
> > Hi
> >
> > On 7/14/25 15:38, Larry Garfield wrote:
> > > Thanks, Ilija.  You expressed my concerns as well.  And yes, in pr=
actice, readonly classes over-reaching is the main use case; if you're m=
arking individual properties readonly, then just don't mark the one that=
 has a hook on it (use aviz if needed) and there's no issue.
> >
> > A readonly class is not just a convenience shortcut to mark each
> > individual property as readonly. It has important semantics of its o=
wn,
> > because it forces child classes to also be readonly. And even for fi=
nal
> > classes it communicates to the user that "I won't be adding non-read=
only
> > properties to the class".
> >
> >
> > Wasn=E2=80=99t that the entire point of readonly classes? Because it=
 was painful to write readonly for every property. Then if a property is=
 readonly, the inherited property is also readonly, so, by extension: a =
class extending a readonly class is also readonly.
> >
> > There=E2=80=99s no =E2=80=9Ccommunication=E2=80=9D here; just logic.
> >
> >
> > Marking a class as readonly must therefore be a deliberate decision,
> > since it affects the public API of your class and in turn also user
> > expectations.
> >
> >
> > Not really. I can remove the readonly designation and manually mark =
every property as readonly. The behavior of the class doesn=E2=80=99t ma=
gically change. Or, at least, I hope it doesn=E2=80=99t.
> >
> >
> > > Perhaps we're thinking about this the wrong way, though?  So far w=
e've talked as though readonly makes the property write-once.  But... wh=
at if we think of it as applying to the field, aka the backing value?
> >
> > I think of readonly from the view of the public API surface of an
> > object. The property hooks RFC was very explicit in that property ho=
oks
> > are intended to be =E2=80=9Ctransparent to the user=E2=80=9D and can=
 be added without
> > breaking the public API. In other words: Whether or not a property is
> > implemented using a hook should be considered an implementation deta=
il
> > and as a user of a class I do not care whether there is a backing va=
lue
> > or not.
> >
> > > So readonly doesn't limit calling the get hook, or even the set ho=
ok, multiple times.  Only writing to the actual value in the object tabl=
e.  That gives the exact same set of guarantees that a getX()/setX() met=
hod would give.  The methods can be called any number of times, but the =
stored value can only be written once.
> >
> > As a user of a class the "backing table" is mostly inaccessible to me
> > when interacting with objects. It's only exposed via var_dump() and
> > serialize(), the former of which is a debug functionality and the ou=
tput
> > of latter not something I must touch.
> >
> > > It would not guarantee $foo->bar =3D=3D=3D $foo->bar in all cases =
(though that would likely hold in the 99% case in practice), but then, $=
foo->getBar() =3D=3D=3D $foo->getBar() has never been guaranteed either.
> >
> > Properties and methods are something different. For methods there a
> > reasonable expectation that *behavior* is associated with them, for
> > properties there is not.
> >
> >
> > Unless I missed something. Hooks are fancy methods? There is nothing=
 intrinsic about object properties. There is nothing that says two calls=
 to the same property=E2=80=99s getters are going to result in the same =
values. There is asynchronous php, declare ticks, etc. especially in the=
 case of globals, there is no guarantee you even have the same object. A=
t the end of the day, it is up to the programmer building that system / =
program to provide those guarantees=E2=80=94 not the language.
>=20
> I do think that, without any additional information, it would be
> reasonable to assume that `$foo->bar =3D=3D=3D $foo->bar`, i.e. there =
would
> not be side-effects until you've called a method or written to the
> object in some way. So I share Tim's opinion here, but I do agree that
> with hooks available this is not actually a guarantee. You could
> certainly have a `$foo->random_value` property and document that it
> will be different each time you call it.
>=20
> That said, once the programmer has added the readonly designation to a
> property, I do think that something says that two calls to the same
> property will result in the same values - the readonly designation. I
> disagree with the point that it's not up to the language - the
> language should provide an affordance for enforcing programmer intent,
> and I see no reason to even have a readonly designation if we're going
> to make it easily circumventable or otherwise just a "hint".
>=20
> It seems that one common counterpoint to the "let's not make it
> circumventable" argument is to point out that it's already
> circumventable via __get. I agree with Claude that this is not a
> justification for making it *easier* to circumvent. I would also like
> to note that the original RFC
> (https://wiki.php.net/rfc/readonly_properties_v2#unset) seems to allow
> this behavior *for the purpose of lazy initialization*. With an `init`
> hook, we'd have solved this problem, and could deprecate the `__get`
> hack for `readonly` properties / classes.
>=20
> Nicolas Grekas said "__get is certainly not legacy; removing it would
> break many use cases without proper alternatives.", but note that I'm
> only suggesting we could maybe deprecate __get for `readonly`
> properties once we had an `init` hook - I'm not proposing deprecating
> it generally. Without a counterexample, I don't think there would be
> another reason for `__get` to work with `readonly` properties.
>=20

I personally feel that making special restrictions and affordances to re=
adonly classes is a bad language design. It is a =E2=80=9Cclass=E2=80=9D=
 and not something special or different like an enum. This is just a cla=
ss with its properties made readonly. The word says it all =E2=80=94 rea=
d. Only.

Personally, I don=E2=80=99t use readonly much any more. The amount of re=
strictions and weird behavior just makes it impossible for any real-worl=
d use except for narrow cases the original authors of the feature dreame=
d up. With hooks and asymmetrical viz, it=E2=80=99s nearly an obsolete f=
eature anyway.=20

=E2=80=94 Rob
--2e4b967d7982479db0c6d86a87a44d7c
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 18, 2025, at 18:48, Eric Norris wrote:</di=
v><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Fri, Jul 18, 20=
25 at 12:01=E2=80=AFPM Rob Landers &lt;<a href=3D"mailto:rob@bottled.cod=
es">rob@bottled.codes</a>&gt; wrote:</div><div>&gt;</div><div>&gt;</div>=
<div>&gt;</div><div>&gt; On Fri, Jul 18, 2025, at 17:25, Tim D=C3=BCster=
hus wrote:</div><div>&gt;</div><div>&gt; Hi</div><div>&gt;</div><div>&gt=
; On 7/14/25 15:38, Larry Garfield wrote:</div><div>&gt; &gt; Thanks, Il=
ija.&nbsp; You expressed my concerns as well.&nbsp; And yes, in practice=
, readonly classes over-reaching is the main use case; if you're marking=
 individual properties readonly, then just don't mark the one that has a=
 hook on it (use aviz if needed) and there's no issue.</div><div>&gt;</d=
iv><div>&gt; A readonly class is not just a convenience shortcut to mark=
 each</div><div>&gt; individual property as readonly. It has important s=
emantics of its own,</div><div>&gt; because it forces child classes to a=
lso be readonly. And even for final</div><div>&gt; classes it communicat=
es to the user that "I won't be adding non-readonly</div><div>&gt; prope=
rties to the class".</div><div>&gt;</div><div>&gt;</div><div>&gt; Wasn=E2=
=80=99t that the entire point of readonly classes? Because it was painfu=
l to write readonly for every property. Then if a property is readonly, =
the inherited property is also readonly, so, by extension: a class exten=
ding a readonly class is also readonly.</div><div>&gt;</div><div>&gt; Th=
ere=E2=80=99s no =E2=80=9Ccommunication=E2=80=9D here; just logic.</div>=
<div>&gt;</div><div>&gt;</div><div>&gt; Marking a class as readonly must=
 therefore be a deliberate decision,</div><div>&gt; since it affects the=
 public API of your class and in turn also user</div><div>&gt; expectati=
ons.</div><div>&gt;</div><div>&gt;</div><div>&gt; Not really. I can remo=
ve the readonly designation and manually mark every property as readonly=
. The behavior of the class doesn=E2=80=99t magically change. Or, at lea=
st, I hope it doesn=E2=80=99t.</div><div>&gt;</div><div>&gt;</div><div>&=
gt; &gt; Perhaps we're thinking about this the wrong way, though?&nbsp; =
So far we've talked as though readonly makes the property write-once.&nb=
sp; But... what if we think of it as applying to the field, aka the back=
ing value?</div><div>&gt;</div><div>&gt; I think of readonly from the vi=
ew of the public API surface of an</div><div>&gt; object. The property h=
ooks RFC was very explicit in that property hooks</div><div>&gt; are int=
ended to be =E2=80=9Ctransparent to the user=E2=80=9D and can be added w=
ithout</div><div>&gt; breaking the public API. In other words: Whether o=
r not a property is</div><div>&gt; implemented using a hook should be co=
nsidered an implementation detail</div><div>&gt; and as a user of a clas=
s I do not care whether there is a backing value</div><div>&gt; or not.<=
/div><div>&gt;</div><div>&gt; &gt; So readonly doesn't limit calling the=
 get hook, or even the set hook, multiple times.&nbsp; Only writing to t=
he actual value in the object table.&nbsp; That gives the exact same set=
 of guarantees that a getX()/setX() method would give.&nbsp; The methods=
 can be called any number of times, but the stored value can only be wri=
tten once.</div><div>&gt;</div><div>&gt; As a user of a class the "backi=
ng table" is mostly inaccessible to me</div><div>&gt; when interacting w=
ith objects. It's only exposed via var_dump() and</div><div>&gt; seriali=
ze(), the former of which is a debug functionality and the output</div><=
div>&gt; of latter not something I must touch.</div><div>&gt;</div><div>=
&gt; &gt; It would not guarantee $foo-&gt;bar =3D=3D=3D $foo-&gt;bar in =
all cases (though that would likely hold in the 99% case in practice), b=
ut then, $foo-&gt;getBar() =3D=3D=3D $foo-&gt;getBar() has never been gu=
aranteed either.</div><div>&gt;</div><div>&gt; Properties and methods ar=
e something different. For methods there a</div><div>&gt; reasonable exp=
ectation that *behavior* is associated with them, for</div><div>&gt; pro=
perties there is not.</div><div>&gt;</div><div>&gt;</div><div>&gt; Unles=
s I missed something. Hooks are fancy methods? There is nothing intrinsi=
c about object properties. There is nothing that says two calls to the s=
ame property=E2=80=99s getters are going to result in the same values. T=
here is asynchronous php, declare ticks, etc. especially in the case of =
globals, there is no guarantee you even have the same object. At the end=
 of the day, it is up to the programmer building that system / program t=
o provide those guarantees=E2=80=94 not the language.</div><div><br></di=
v><div>I do think that, without any additional information, it would be<=
/div><div>reasonable to assume that `$foo-&gt;bar =3D=3D=3D $foo-&gt;bar=
`, i.e. there would</div><div>not be side-effects until you've called a =
method or written to the</div><div>object in some way. So I share Tim's =
opinion here, but I do agree that</div><div>with hooks available this is=
 not actually a guarantee. You could</div><div>certainly have a `$foo-&g=
t;random_value` property and document that it</div><div>will be differen=
t each time you call it.</div><div><br></div><div>That said, once the pr=
ogrammer has added the readonly designation to a</div><div>property, I d=
o think that something says that two calls to the same</div><div>propert=
y will result in the same values - the readonly designation. I</div><div=
>disagree with the point that it's not up to the language - the</div><di=
v>language should provide an affordance for enforcing programmer intent,=
</div><div>and I see no reason to even have a readonly designation if we=
're going</div><div>to make it easily circumventable or otherwise just a=
 "hint".</div><div><br></div><div>It seems that one common counterpoint =
to the "let's not make it</div><div>circumventable" argument is to point=
 out that it's already</div><div>circumventable via __get. I agree with =
Claude that this is not a</div><div>justification for making it *easier*=
 to circumvent. I would also like</div><div>to note that the original RF=
C</div><div>(<a href=3D"https://wiki.php.net/rfc/readonly_properties_v2#=
unset">https://wiki.php.net/rfc/readonly_properties_v2#unset</a>) seems =
to allow</div><div>this behavior *for the purpose of lazy initialization=
*. With an `init`</div><div>hook, we'd have solved this problem, and cou=
ld deprecate the `__get`</div><div>hack for `readonly` properties / clas=
ses.</div><div><br></div><div>Nicolas Grekas said "__get is certainly no=
t legacy; removing it would</div><div>break many use cases without prope=
r alternatives.", but note that I'm</div><div>only suggesting we could m=
aybe deprecate __get for `readonly`</div><div>properties once we had an =
`init` hook - I'm not proposing deprecating</div><div>it generally. With=
out a counterexample, I don't think there would be</div><div>another rea=
son for `__get` to work with `readonly` properties.</div><div><br></div>=
</blockquote><div><br></div><div>I personally feel that making special r=
estrictions and affordances to readonly classes is a bad language design=
. It is a =E2=80=9Cclass=E2=80=9D and not something special or different=
 like an enum. This is just a class with its properties made readonly. T=
he word says it all =E2=80=94 read. Only.</div><div><br></div><div>Perso=
nally, I don=E2=80=99t use readonly much any more. The amount of restric=
tions and weird behavior just makes it impossible for any real-world use=
 except for narrow cases the original authors of the feature dreamed up.=
 With hooks and asymmetrical viz, it=E2=80=99s nearly an obsolete featur=
e anyway.&nbsp;</div><div><br></div><div id=3D"sig121229152">=E2=80=94 R=
ob</div></body></html>
--2e4b967d7982479db0c6d86a87a44d7c--