Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128129
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 19 Jul 2025 00:36:06 +0200
To: erictnorris@gmail.com, "Nicolas Grekas" <nicolas.grekas+php@gmail.com>,
 "Larry Garfield" <larry@garfieldtech.com>
Cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 "php internals" <internals@lists.php.net>
Message-ID: <378cd8b0-c4a8-4e53-b0bd-e9e4f30a454d@app.fastmail.com>
In-Reply-To: 
 <CA+NMNO3LqD+zFEF3pZYHE8X76qPcVBhZgbbZxdO1qFsXbF=-Rw@mail.gmail.com>
References: <1e8634d7-ac1a-4025-b4e2-1948aabf5251@app.fastmail.com>
 <09780759-9ddc-45e2-9376-befb8e378775@app.fastmail.com>
 <0e8eb146-3b1d-4fc2-ad83-77062f2063c9@bastelstu.be>
 <CAOWwgpmw7jcvebZKxfN0y9zXuncW4OA4SxCrWGUjyWB-1HTWuA@mail.gmail.com>
 <CA+NMNO3LqD+zFEF3pZYHE8X76qPcVBhZgbbZxdO1qFsXbF=-Rw@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] Readonly property hooks
Content-Type: multipart/alternative;
 boundary=16c3cc64a348406ea3d78ce7c610b9e6
From: rob@bottled.codes ("Rob Landers")

--16c3cc64a348406ea3d78ce7c610b9e6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Jul 18, 2025, at 21:43, Eric Norris wrote:
> Nick, Larry,
>=20
> On Fri, Jul 18, 2025 at 2:01=E2=80=AFPM Nicolas Grekas
> <nicolas.grekas+php@gmail.com <mailto:nicolas.grekas%2Bphp@gmail.com>>=
 wrote:
> >
> >
> >
> > Le ven. 18 juil. 2025 =C3=A0 18:32, Tim D=C3=BCsterhus <tim@bastelst=
u.be> a =C3=A9crit :
> >>
> >> Hi
> >>
> >> On 7/17/25 18:26, Larry Garfield wrote:
> >> > Given the lack of consensus both here and in off-list discussions=
 on how to handle get hooks, we have done the following:
> >> >
> >> > * Split the RFC into two sections, one for get, one for set.
> >> > * Expanded and refined the examples for both. The implementation =
is still the original, however.
> >> > * Split the vote into two: one for allowing readonly get hooks, o=
ne for readonly set hooks.
> >> >
> >> > We will start the vote sometime this weekend, most likely, unless=
 some major feedback appears before then, and let the chips fall where t=
hey may.
> >>
> >> After working through (most of) the discussion, I've now taken a lo=
ok at
> >> the updated RFC. I have the following remarks:
> >>
> >> 1.
> >>
> >> > It is really =E2=80=9Cwrite-once=E2=80=9D, which is not the same =
as immutable (as shown above). But there's no reason that =E2=80=9Cwrite=
-once=E2=80=9D need be incompatible with hooks.
> >>
> >> This is a strawman argumentation, as I've outlined in my previous
> >> emails, calling readonly "write-once" is wrong. It is a reasonable =
user
> >> expectation to always get the identical value when reading a value =
that
> >> may only be set once. By calling it "write-once" you are trying to =
shift
> >> the focus to the write operation, which is totally irrelevant for u=
ser
> >> expectations when interacting with readonly properties. Especially =
for
> >> expectations of users that just *use* a class rather than writing o=
ne.
> >
> >
> > To my ears, write-once is more accurate than readonly because it sti=
cks to the facts of how this behaves. That's very relevant.
> > Using readonly to suggest immutable is where the arguments for rejec=
ting this RFC are weak.
> > readonly doesn't mean immutable, no matter how hard some want it to =
be...
>=20
> (including a snippet from a separate email from Larry below)
>=20
> > Does readonly refer to the value returned?  If so, that's already be=
en broken since the beginning because the property can be a mutable obje=
ct, so trusting the data returned to be "the same" is already not safe.
>=20
> It seems to me that the original intent of `readonly` was to mean
> immutable, and points to a property always equaling itself in the
> rationale section
> (https://wiki.php.net/rfc/readonly_properties_v2#rationale):
>=20
> ```
> $prop =3D $this->prop;
> $fn(); // Any code may run here.
> $prop2 =3D $this->prop;
> assert($prop =3D=3D=3D $prop2); // Always holds.
> ```
>=20
> It even calls out that this *does not* restrict *interior* mutability,
> which I believe you are using to argue that it doesn't actually mean
> immutable:
>=20
> "However, readonly properties do not preclude interior mutability.
> Objects (or resources) stored in readonly properties may still be
> modified internally."
>=20
> This is exactly how I think about `readonly`. The identity of property
> won't change, but the object itself might. Now if the object is also a
> `readonly` class (and recursive for any of those class's properties
> that are objects), then you *would* truly have an immutability
> guarantee of both the identity of the object and the object's
> properties. This is ignoring __get, which I have pointed out elsewhere
> is worth ignoring, since we can conceivably remove that from readonly
> classes if we pass `init` hooks.

I don't want to accuse you of cherry-picking ... but this is clearly che=
rry picking. From that same text:

---

It is worth noting that having a readonly property feature does not prec=
lude introduction of accessors. C# supports both readonly properties and=
 accessors. C# also provides properties with implicit backing storage th=
rough accessor syntax, but this is not the only way to do it. For exampl=
e, Swift has special syntax for asymmetric visibility, rather than speci=
fying visibility on implicitly implemented accessors.
Even if we have property accessors, I believe it may be worthwhile to li=
mit them to computed properties only, and solve use-cases that involve e=
ngine-managed storage through other mechanisms, such as readonly propert=
ies and property-level asymmetric visibility. This avoids confusion rela=
ting to the two kinds of accessors (implicit and explicit), and also all=
ows us to make their behavior independent of accessor constraints. For e=
xample, a first-class asymmetric visibility feature would shield the use=
r from considering distinctions such as `get;` vs `&get;` accessors. The=
se are externalities of the general accessor feature and not needed for =
asymmetric visibility.
A separate implementation can also be more efficient. After initializati=
on, a readonly property will have the same performance characteristics a=
s a normal property. Accessor-based properties, even with implicit stora=
ge, still carry a performance penalty.

---

The original author (Nikita) suggested that there's nothing in the origi=
nal design that precludes accessors -- and highlights languages where th=
ere are both and they are doing just fine more than 5 years later.

[snip]

> I am failing to understand what capabilities are not going to be
> addressed by an `init` hook, which some of us (if I'm allowed to speak
> for us) seem to think is the correct approach here.
>=20
> I have noticed in some discussions with my coworkers that it seems
> that some people think that readonly implies a *contract about
> writability to consumers of the class*, that is, it implies that
> consumers of the class can only *read* the value, not write it. I
> think I could understand why people that think this way would have no
> problem with `get` hooks, since it still upholds what they think the
> contract is. I feel, however, that that desired contract is actually
> achieved by asymmetric visibility, e.g. public(get) protected(set),
> which I view as orthogonal to readonly.
>=20
> When I point out that asymmetric visibility exists, everyone I've
> talked to so far agrees that readonly makes more sense as a *contract
> that the value won't change*. And, as I've pointed out above, I
> believe that is the intent of the original RFC text for the feature.
>=20
> With this understanding of the contract of readonly, I struggle to
> understand why an author *who wants to use readonly* would need `get`
> hook capabilities and not in fact `init` hook capabilities. If they
> needed generic `get` hook capabilities for a property (and not just
> lazy loading), then my position is that *they don't actually want
> readonly*.
>=20

I think an init hook is out of the question for 8.5, so I'm not even sur=
e it's worth discussing.

=E2=80=94 Rob
--16c3cc64a348406ea3d78ce7c610b9e6
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 21:43, Eric Norris wrote:</di=
v><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Nick, Larry,</div>=
<div><br></div><div>On Fri, Jul 18, 2025 at 2:01=E2=80=AFPM Nicolas Grek=
as</div><div>&lt;<a href=3D"mailto:nicolas.grekas%2Bphp@gmail.com">nicol=
as.grekas+php@gmail.com</a>&gt; wrote:</div><div>&gt;</div><div>&gt;</di=
v><div>&gt;</div><div>&gt; Le ven. 18 juil. 2025 =C3=A0 18:32, Tim D=C3=BC=
sterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@bastelstu.be</a>&gt;=
 a =C3=A9crit :</div><div>&gt;&gt;</div><div>&gt;&gt; Hi</div><div>&gt;&=
gt;</div><div>&gt;&gt; On 7/17/25 18:26, Larry Garfield wrote:</div><div=
>&gt;&gt; &gt; Given the lack of consensus both here and in off-list dis=
cussions on how to handle get hooks, we have done the following:</div><d=
iv>&gt;&gt; &gt;</div><div>&gt;&gt; &gt; * Split the RFC into two sectio=
ns, one for get, one for set.</div><div>&gt;&gt; &gt; * Expanded and ref=
ined the examples for both. The implementation is still the original, ho=
wever.</div><div>&gt;&gt; &gt; * Split the vote into two: one for allowi=
ng readonly get hooks, one for readonly set hooks.</div><div>&gt;&gt; &g=
t;</div><div>&gt;&gt; &gt; We will start the vote sometime this weekend,=
 most likely, unless some major feedback appears before then, and let th=
e chips fall where they may.</div><div>&gt;&gt;</div><div>&gt;&gt; After=
 working through (most of) the discussion, I've now taken a look at</div=
><div>&gt;&gt; the updated RFC. I have the following remarks:</div><div>=
&gt;&gt;</div><div>&gt;&gt; 1.</div><div>&gt;&gt;</div><div>&gt;&gt; &gt=
; It is really =E2=80=9Cwrite-once=E2=80=9D, which is not the same as im=
mutable (as shown above). But there's no reason that =E2=80=9Cwrite-once=
=E2=80=9D need be incompatible with hooks.</div><div>&gt;&gt;</div><div>=
&gt;&gt; This is a strawman argumentation, as I've outlined in my previo=
us</div><div>&gt;&gt; emails, calling readonly "write-once" is wrong. It=
 is a reasonable user</div><div>&gt;&gt; expectation to always get the i=
dentical value when reading a value that</div><div>&gt;&gt; may only be =
set once. By calling it "write-once" you are trying to shift</div><div>&=
gt;&gt; the focus to the write operation, which is totally irrelevant fo=
r user</div><div>&gt;&gt; expectations when interacting with readonly pr=
operties. Especially for</div><div>&gt;&gt; expectations of users that j=
ust *use* a class rather than writing one.</div><div>&gt;</div><div>&gt;=
</div><div>&gt; To my ears, write-once is more accurate than readonly be=
cause it sticks to the facts of how this behaves. That's very relevant.<=
/div><div>&gt; Using readonly to suggest immutable is where the argument=
s for rejecting this RFC are weak.</div><div>&gt; readonly doesn't mean =
immutable, no matter how hard some want it to be...</div><div><br></div>=
<div>(including a snippet from a separate email from Larry below)</div><=
div><br></div><div>&gt; Does readonly refer to the value returned?&nbsp;=
 If so, that's already been broken since the beginning because the prope=
rty can be a mutable object, so trusting the data returned to be "the sa=
me" is already not safe.</div><div><br></div><div>It seems to me that th=
e original intent of `readonly` was to mean</div><div>immutable, and poi=
nts to a property always equaling itself in the</div><div>rationale sect=
ion</div><div>(<a href=3D"https://wiki.php.net/rfc/readonly_properties_v=
2#rationale">https://wiki.php.net/rfc/readonly_properties_v2#rationale</=
a>):</div><div><br></div><div>```</div><div>$prop =3D $this-&gt;prop;</d=
iv><div>$fn(); // Any code may run here.</div><div>$prop2 =3D $this-&gt;=
prop;</div><div>assert($prop =3D=3D=3D $prop2); // Always holds.</div><d=
iv>```</div><div><br></div><div>It even calls out that this *does not* r=
estrict *interior* mutability,</div><div>which I believe you are using t=
o argue that it doesn't actually mean</div><div>immutable:</div><div><br=
></div><div>"However, readonly properties do not preclude interior mutab=
ility.</div><div>Objects (or resources) stored in readonly properties ma=
y still be</div><div>modified internally."</div><div><br></div><div>This=
 is exactly how I think about `readonly`. The identity of property</div>=
<div>won't change, but the object itself might. Now if the object is als=
o a</div><div>`readonly` class (and recursive for any of those class's p=
roperties</div><div>that are objects), then you *would* truly have an im=
mutability</div><div>guarantee of both the identity of the object and th=
e object's</div><div>properties. This is ignoring __get, which I have po=
inted out elsewhere</div><div>is worth ignoring, since we can conceivabl=
y remove that from readonly</div><div>classes if we pass `init` hooks.</=
div></blockquote><div><br></div><div>I don't want to accuse you of cherr=
y-picking ... but this is clearly cherry picking. From that same text:</=
div><div><br></div><div>---</div><div><br></div><div class=3D"align-star=
t" style=3D"text-align:start;">It is worth noting that having a readonly=
 property feature does not preclude introduction of accessors. C# suppor=
ts both readonly properties and accessors. C# also provides properties w=
ith implicit backing storage through accessor syntax, but this is not th=
e only way to do it. For example, Swift has special syntax for asymmetri=
c visibility, rather than specifying visibility on implicitly implemente=
d accessors.</div><div class=3D"align-start" style=3D"text-align:start;"=
>Even if we have property accessors, I believe it may be worthwhile to l=
imit them to computed properties only, and solve use-cases that involve =
engine-managed storage through other mechanisms, such as readonly proper=
ties and property-level asymmetric visibility. This avoids confusion rel=
ating to the two kinds of accessors (implicit and explicit), and also al=
lows us to make their behavior independent of accessor constraints. For =
example, a first-class asymmetric visibility feature would shield the us=
er from considering distinctions such as&nbsp;<code style=3D"border-top-=
width:1px;border-right-width:1px;border-bottom-width:1px;border-left-wid=
th:1px;border-top-style:solid;border-right-style:solid;border-bottom-sty=
le:solid;border-left-style:solid;border-top-color:#ccc;border-right-colo=
r:#ccc;border-bottom-color:#ccc;border-left-color:#ccc;border-image-sour=
ce:initial;border-image-slice:initial;border-image-width:initial;border-=
image-outset:initial;border-image-repeat:initial;border-top-left-radius:=
3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bo=
ttom-left-radius:3px;background-image:initial;background-position-x:init=
ial;background-position-y:initial;background-size:initial;background-rep=
eat:initial;background-attachment:initial;background-origin:initial;back=
ground-clip:initial;background-color:#f6f6f6;font-family:menlo, consolas=
, monospace;font-size:90%;padding-top:1px;padding-right:3px;padding-bott=
om:1px;padding-left:3px;">get;</code>&nbsp;vs&nbsp;<code style=3D"border=
-top-width:1px;border-right-width:1px;border-bottom-width:1px;border-lef=
t-width:1px;border-top-style:solid;border-right-style:solid;border-botto=
m-style:solid;border-left-style:solid;border-top-color:#ccc;border-right=
-color:#ccc;border-bottom-color:#ccc;border-left-color:#ccc;border-image=
-source:initial;border-image-slice:initial;border-image-width:initial;bo=
rder-image-outset:initial;border-image-repeat:initial;border-top-left-ra=
dius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;bord=
er-bottom-left-radius:3px;background-image:initial;background-position-x=
:initial;background-position-y:initial;background-size:initial;backgroun=
d-repeat:initial;background-attachment:initial;background-origin:initial=
;background-clip:initial;background-color:#f6f6f6;font-family:menlo, con=
solas, monospace;font-size:90%;padding-top:1px;padding-right:3px;padding=
-bottom:1px;padding-left:3px;">&amp;get;</code>&nbsp;accessors. These ar=
e externalities of the general accessor feature and not needed for asymm=
etric visibility.</div><div class=3D"align-start" style=3D"text-align:st=
art;">A separate implementation can also be more efficient. After initia=
lization, a readonly property will have the same performance characteris=
tics as a normal property. Accessor-based properties, even with implicit=
 storage, still carry a performance penalty.</div><div class=3D"align-st=
art" style=3D"text-align:start;"><br></div><div class=3D"align-start" st=
yle=3D"text-align:start;">---</div><div class=3D"align-start" style=3D"t=
ext-align:start;"><br></div><div class=3D"align-start" style=3D"text-ali=
gn:start;">The original author (Nikita) suggested that there's nothing i=
n the original design that precludes accessors -- and highlights languag=
es where there are both and they are doing just fine more than 5 years l=
ater.</div><div class=3D"align-start" style=3D"text-align:start;"><br></=
div><div class=3D"align-start" style=3D"text-align:start;">[snip]</div><=
div class=3D"align-start" style=3D"text-align:start;"><br></div><blockqu=
ote type=3D"cite" id=3D"qt" style=3D""><div>I am failing to understand w=
hat capabilities are not going to be</div><div>addressed by an `init` ho=
ok, which some of us (if I'm allowed to speak</div><div>for us) seem to =
think is the correct approach here.</div><div><br></div><div>I have noti=
ced in some discussions with my coworkers that it seems</div><div>that s=
ome people think that readonly implies a *contract about</div><div>writa=
bility to consumers of the class*, that is, it implies that</div><div>co=
nsumers of the class can only *read* the value, not write it. I</div><di=
v>think I could understand why people that think this way would have no<=
/div><div>problem with `get` hooks, since it still upholds what they thi=
nk the</div><div>contract is. I feel, however, that that desired contrac=
t is actually</div><div>achieved by asymmetric visibility, e.g. public(g=
et) protected(set),</div><div>which I view as orthogonal to readonly.</d=
iv><div><br></div><div>When I point out that asymmetric visibility exist=
s, everyone I've</div><div>talked to so far agrees that readonly makes m=
ore sense as a *contract</div><div>that the value won't change*. And, as=
 I've pointed out above, I</div><div>believe that is the intent of the o=
riginal RFC text for the feature.</div><div><br></div><div>With this und=
erstanding of the contract of readonly, I struggle to</div><div>understa=
nd why an author *who wants to use readonly* would need `get`</div><div>=
hook capabilities and not in fact `init` hook capabilities. If they</div=
><div>needed generic `get` hook capabilities for a property (and not jus=
t</div><div>lazy loading), then my position is that *they don't actually=
 want</div><div>readonly*.</div><div><br></div></blockquote><div><br></d=
iv><div>I think an init hook is out of the question for 8.5, so I'm not =
even sure it's worth discussing.</div><div><br></div><div id=3D"sig12122=
9152">=E2=80=94 Rob</div></body></html>
--16c3cc64a348406ea3d78ce7c610b9e6--