Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128115
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 18 Jul 2025 17:49:38 +0200
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 "Larry Garfield" <larry@garfieldtech.com>,
 "php internals" <internals@lists.php.net>
Message-ID: <0d9a2968-26dd-43dd-9733-d2eb621ab9ec@app.fastmail.com>
In-Reply-To: <2641b8bc-6337-4b75-a5a3-93dee1b03796@bastelstu.be>
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>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
Content-Type: multipart/alternative;
 boundary=95102c3e917842f48531ca5180ac48c3
From: rob@bottled.codes ("Rob Landers")

--95102c3e917842f48531ca5180ac48c3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Jul 18, 2025, at 17:25, Tim D=C3=BCsterhus wrote:
> Hi
>=20
> On 7/14/25 15:38, Larry Garfield wrote:
> > Thanks, Ilija.  You expressed my concerns as well.  And yes, in prac=
tice, readonly classes over-reaching is the main use case; if you're mar=
king individual properties readonly, then just don't mark the one that h=
as a hook on it (use aviz if needed) and there's no issue.
>=20
> A readonly class is not just a convenience shortcut to mark each=20
> individual property as readonly. It has important semantics of its own=
,=20
> because it forces child classes to also be readonly. And even for fina=
l=20
> classes it communicates to the user that "I won't be adding non-readon=
ly=20
> 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 rea=
donly, the inherited property is also readonly, so, by extension: a clas=
s extending a readonly class is also readonly.

There=E2=80=99s no =E2=80=9Ccommunication=E2=80=9D here; just logic.=20

>=20
> Marking a class as readonly must therefore be a deliberate decision,=20
> since it affects the public API of your class and in turn also user=20
> expectations.

Not really. I can remove the readonly designation and manually mark ever=
y property as readonly. The behavior of the class doesn=E2=80=99t magica=
lly change. Or, at least, I hope it doesn=E2=80=99t.=20

>=20
> > Perhaps we're thinking about this the wrong way, though?  So far we'=
ve talked as though readonly makes the property write-once.  But... what=
 if we think of it as applying to the field, aka the backing value?
>=20
> I think of readonly from the view of the public API surface of an=20
> object. The property hooks RFC was very explicit in that property hook=
s=20
> are intended to be =E2=80=9Ctransparent to the user=E2=80=9D and can b=
e added without=20
> breaking the public API. In other words: Whether or not a property is=20
> implemented using a hook should be considered an implementation detail=20
> and as a user of a class I do not care whether there is a backing valu=
e=20
> or not.
>=20
> > So readonly doesn't limit calling the get hook, or even the set hook=
, multiple times.  Only writing to the actual value in the object table.=
  That gives the exact same set of guarantees that a getX()/setX() metho=
d would give.  The methods can be called any number of times, but the st=
ored value can only be written once.
>=20
> As a user of a class the "backing table" is mostly inaccessible to me=20
> when interacting with objects. It's only exposed via var_dump() and=20
> serialize(), the former of which is a debug functionality and the outp=
ut=20
> of latter not something I must touch.
>=20
> > It would not guarantee $foo->bar =3D=3D=3D $foo->bar in all cases (t=
hough that would likely hold in the 99% case in practice), but then, $fo=
o->getBar() =3D=3D=3D $foo->getBar() has never been guaranteed either.
>=20
> Properties and methods are something different. For methods there a=20
> reasonable expectation that *behavior* is associated with them, for=20
> properties there is not.

Unless I missed something. Hooks are fancy methods? There is nothing int=
rinsic 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 valu=
es. There is asynchronous php, declare ticks, etc. especially in the cas=
e of globals, there is no guarantee you even have the same object. At th=
e end of the day, it is up to the programmer building that system / prog=
ram to provide those guarantees=E2=80=94 not the language.=20

>=20
> A 99% case is not sufficient for me to rely on when there's explicit=20
> communication by the class author that I may rely on properties not=20
> suddenly changing.
>=20
> Best regards
> Tim D=C3=BCsterhus
>=20

=E2=80=94 Rob
--95102c3e917842f48531ca5180ac48c3
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 17:25, Tim D=C3=BCsterhus wro=
te:</div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi</div><di=
v><br></div><div>On 7/14/25 15:38, Larry Garfield wrote:</div><div>&gt; =
Thanks, Ilija.&nbsp; You expressed my concerns as well.&nbsp; And yes, i=
n 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><d=
iv><br></div><div>A readonly class is not just a convenience shortcut to=
 mark each&nbsp;</div><div>individual property as readonly. It has impor=
tant semantics of its own,&nbsp;</div><div>because it forces child class=
es to also be readonly. And even for final&nbsp;</div><div>classes it co=
mmunicates to the user that "I won't be adding non-readonly&nbsp;</div><=
div>properties to the class".</div></blockquote><div><br></div><div>Wasn=
=E2=80=99t that the entire point of readonly classes? Because it was pai=
nful to write readonly for every property. Then if a property is readonl=
y, the inherited property is also readonly, so, by extension: a class ex=
tending a readonly class is also readonly.</div><div><br></div><div>Ther=
e=E2=80=99s no =E2=80=9Ccommunication=E2=80=9D here; just logic.&nbsp;</=
div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><=
br></div><div>Marking a class as readonly must therefore be a deliberate=
 decision,&nbsp;</div><div>since it affects the public API of your class=
 and in turn also user&nbsp;</div><div>expectations.</div></blockquote><=
div><br></div><div>Not really. I can remove the readonly designation and=
 manually mark every property as readonly. The behavior of the class doe=
sn=E2=80=99t magically change. Or, at least, I hope it doesn=E2=80=99t.&=
nbsp;</div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""=
><div><br></div><div>&gt; Perhaps we're thinking about this the wrong wa=
y, though?&nbsp; So far we've talked as though readonly makes the proper=
ty write-once.&nbsp; But... what if we think of it as applying to the fi=
eld, aka the backing value?</div><div><br></div><div>I think of readonly=
 from the view of the public API surface of an&nbsp;</div><div>object. T=
he property hooks RFC was very explicit in that property hooks&nbsp;</di=
v><div>are intended to be =E2=80=9Ctransparent to the user=E2=80=9D and =
can be added without&nbsp;</div><div>breaking the public API. In other w=
ords: Whether or not a property is&nbsp;</div><div>implemented using a h=
ook should be considered an implementation detail&nbsp;</div><div>and as=
 a user of a class I do not care whether there is a backing value&nbsp;<=
/div><div>or not.</div><div><br></div><div>&gt; So readonly doesn't limi=
t calling the get hook, or even the set hook, multiple times.&nbsp; Only=
 writing to the actual value in the object table.&nbsp; That gives the e=
xact 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 ca=
n only be written once.</div><div><br></div><div>As a user of a class th=
e "backing table" is mostly inaccessible to me&nbsp;</div><div>when inte=
racting with objects. It's only exposed via var_dump() and&nbsp;</div><d=
iv>serialize(), the former of which is a debug functionality and the out=
put&nbsp;</div><div>of latter not something I must touch.</div><div><br>=
</div><div>&gt; It would not guarantee $foo-&gt;bar =3D=3D=3D $foo-&gt;b=
ar in all cases (though that would likely hold in the 99% case in practi=
ce), but then, $foo-&gt;getBar() =3D=3D=3D $foo-&gt;getBar() has never b=
een guaranteed either.</div><div><br></div><div>Properties and methods a=
re something different. For methods there a&nbsp;</div><div>reasonable e=
xpectation that *behavior* is associated with them, for&nbsp;</div><div>=
properties there is not.</div></blockquote><div><br></div><div>Unless I =
missed something. Hooks are fancy methods? There is nothing intrinsic ab=
out 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 glob=
als, 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 to pr=
ovide those guarantees=E2=80=94 not the language.&nbsp;</div><div><br></=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>A=
 99% case is not sufficient for me to rely on when there's explicit&nbsp=
;</div><div>communication by the class author that I may rely on propert=
ies not&nbsp;</div><div>suddenly changing.</div><div><br></div><div>Best=
 regards</div><div>Tim D=C3=BCsterhus</div><div><br></div></blockquote><=
div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--95102c3e917842f48531ca5180ac48c3--