Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127967
Precedence: bulk
MIME-Version: 1.0
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>
 <46857A6D-5EAF-44AF-A2DE-9B40AF8DE8C8@gmail.com>
In-Reply-To: <46857A6D-5EAF-44AF-A2DE-9B40AF8DE8C8@gmail.com>
Date: Wed, 9 Jul 2025 13:39:35 +0200
Message-ID: <CAOWwgpnbCk9T-MoA41i+dA3yCVecchpdymWsM=5FOWbKwXbbLw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Readonly property hooks
To: Claude Pache <claude.pache@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b4b01906397d881b"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000b4b01906397d881b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for your detailed thoughts, Claude. I'd like to offer my perspective
on some of the points you raised.

Le mer. 9 juil. 2025 =C3=A0 12:53, Claude Pache <claude.pache@gmail.com> a
=C3=A9crit :

>
>
> Le 8 juil. 2025 =C3=A0 17:32, Nicolas Grekas <nicolas.grekas+php@gmail.co=
m> a
> =C3=A9crit :
>
> I read Claude's concern, and I agree with Larry's response: the engine
> already allows readonly to be bypassed using __get. The added hook doesn'=
t
> make anything more lenient.
>
>
> It is true that readonly could be bypassed by __get(); but this is a
> legacy behaviour, and you have to take an explicit step to make it
> possible. For those unaware of the awful hack, here is a minimal test cas=
e:
>
> https://3v4l.org/N78An
>
> where the `unset(...)` is mandatory to make it =E2=80=9Cwork=E2=80=9D.
>
> Are we obligated to sanction shortcomings of legacy concepts in newly
> introduced concepts that are supposed to replace them? Or can we do
> something better? I=E2=80=99ve outlined in a previous email what I think =
is a
> better design for such situation (namely an `init` hook).
>
> Also, the fact that __get() is not yet deprecated means that we can still
> use the aforementioned hack until/unless we=E2=80=99ve implemented a prop=
er
> solution. In the worst case, you can still use a non-readonly hooked
> property and document the intended invariants in phpdoc.
>


__get is certainly not legacy; removing it would break many use cases
without proper alternatives.
The behavior after unset() has been promoted to a language feature when
readonly properties were introduced *because* it helps solve real world use
cases.
I've been asked recently by Gina if those use cases were covered by eg
native lazy proxies. The answer is *no*, because native lazy proxies cover
only part of the lazy-proxying domain: what remains is proxying by
interface and proxying internal classes, and those require a way to proxy
all property accesses, which is why magic methods are required.

With the argument that __get can be used to implement the
non-readonly-ness, we could also say that hooks are not needed, because
they can be implemented using __get. Yet, language aesthetics are
important, and we welcomed hooks for this reason. Being able to easily
lazy-init thanks to hooks on readonly would be a welcome improvement to me.

That being said, about your init proposal, I think that could work. I'd
just do it a bit differently: instead of introducing a new "init" hook, I'd
prefer having "set" mean "init" for readonly properties. But I know nothing
about the engine on the topic so I can't comment on the feasibility aspect.
I'll leave this to others.

Just a word about using hooks vs __get for lazy-init: the really hard part
when using __get is emulating the public/protected/private visibility
rules. Hooks make this a non-issue. Yet hooks - unfortunately - can't be
used as a generic lazy-init implementation because of their behavior
related to references. That's another topic, but still related, to
reinforce that __get is certainly not legacy.



>
> If a class is final and uses readonly with either hooks or __get, then
> that's the original author's choice. There's no need for extra
> engine-assisted strictness in this case. You cannot write such code in a
> non-readonly way by mistake, so it has to be by intent.
>
>
> Enforcing as strictly as possible its intended invariants is a good desig=
n
> for a robust language. Yes, it implies that users cannot (or can hardly)
> escape annoying constraints. For example, you can=E2=80=99t extend a fina=
l class,
> even if you think that you have good reason for it, like constructing a
> mock object.
>


That's not strictness when the root concept is already filled with
conceptual holes... I'm surprised nobody ever proposed the concept of an
*immutable* keyword, that'd be like readonly but that'd accept only
also-immutable values. Until this happens, using readonly for that is
a fallacy I'm sorry... To me that invalidates all related arguments.

Nicolas

--000000000000b4b01906397d881b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Thanks for your detailed thoughts, Claude=
. I&#39;d like to offer my perspective on some of the points you raised.</d=
iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">Le=C2=A0mer. 9 juil. 2025 =C3=A0=C2=A012:53, Claude Pach=
e &lt;<a href=3D"mailto:claude.pache@gmail.com">claude.pache@gmail.com</a>&=
gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div><br id=3D"m_-6158636423795100535lineBreakAtBeginningOfMessage"=
><div><br><blockquote type=3D"cite"><div>Le 8 juil. 2025 =C3=A0 17:32, Nico=
las Grekas &lt;<a href=3D"mailto:nicolas.grekas%2Bphp@gmail.com" target=3D"=
_blank">nicolas.grekas+php@gmail.com</a>&gt; a =C3=A9crit :</div><br><div><=
div style=3D"font-family:Helvetica;font-size:14px;font-style:normal;font-va=
riant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-=
decoration:none">I read Claude&#39;s concern, and I agree with Larry&#39;s =
response: the engine already allows readonly to be bypassed using __get. Th=
e added hook doesn&#39;t make anything more lenient.</div><br></div></block=
quote></div><br><div>It is true that readonly could be bypassed by __get();=
 but this is a legacy behaviour, and you have to take an explicit step to m=
ake it possible. For those unaware of the awful hack, here is a minimal tes=
t case:</div><div><br></div><div><a href=3D"https://3v4l.org/N78An" target=
=3D"_blank">https://3v4l.org/N78An</a></div><div><br></div><div>where the `=
unset(...)` is mandatory to make it =E2=80=9Cwork=E2=80=9D.</div><div><br><=
/div><div>Are we obligated to sanction shortcomings of legacy concepts in n=
ewly introduced concepts that are supposed to replace them? Or can we do so=
mething better? I=E2=80=99ve outlined in a previous email what I think is a=
 better design for such situation (namely an `init` hook).</div><div><br></=
div><div>Also, the fact that __get() is not yet deprecated means that we ca=
n still use the aforementioned hack until/unless we=E2=80=99ve implemented =
a proper solution. In the worst case, you can still use a non-readonly hook=
ed property and document the intended invariants in phpdoc.</div></div></bl=
ockquote><div><br></div><div><br></div><div>__get is certainly not legacy; =
removing it would break many use cases without proper alternatives.</div><d=
iv>The behavior after unset() has been promoted to a language feature when =
readonly properties were introduced *because* it helps solve real world use=
 cases.</div><div>I&#39;ve been asked recently by Gina if those use cases w=
ere covered by eg native lazy proxies. The answer is *no*, because native l=
azy proxies cover only part of the lazy-proxying domain: what remains is pr=
oxying by interface and proxying internal classes, and those require a way =
to proxy all property accesses, which is why magic methods are required.</d=
iv><div><br></div><div>With the argument that __get can be used to implemen=
t the non-readonly-ness, we could also say that hooks are not needed, becau=
se they can be implemented using __get.=C2=A0Yet, language aesthetics are i=
mportant, and we welcomed hooks for this reason. Being able to easily lazy-=
init thanks to hooks on readonly would be a welcome improvement to me.</div=
><div><br></div><div>That being said, about your init proposal, I think tha=
t could work. I&#39;d just do it a bit differently: instead of introducing =
a new &quot;init&quot; hook, I&#39;d prefer=C2=A0having &quot;set&quot; mea=
n &quot;init&quot; for readonly properties. But I know nothing about the en=
gine on the topic so I can&#39;t comment on the feasibility aspect. I&#39;l=
l leave this to others.</div><div><br></div><div>Just a word about using ho=
oks vs __get for lazy-init: the really hard part when using __get is emulat=
ing the public/protected/private visibility rules. Hooks make this a non-is=
sue. Yet hooks - unfortunately - can&#39;t be used as a generic=C2=A0lazy-i=
nit implementation because of their behavior related to=C2=A0references. Th=
at&#39;s another topic, but still related, to reinforce that __get is certa=
inly not legacy.</div><div>=C2=A0</div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div><div><br></div><div><br></div><div><div><=
/div></div><blockquote type=3D"cite"><div><div>If a class is final and uses=
 readonly with either hooks or __get, then that&#39;s the original author&#=
39;s choice. There&#39;s no need for extra engine-assisted strictness in th=
is case. You cannot write such code in a non-readonly way by mistake, so it=
 has to be by intent.</div></div><div><br></div></blockquote><div><br></div=
>Enforcing as strictly as possible its intended invariants is a good design=
 for a robust language. Yes, it implies that users cannot (or can hardly) e=
scape annoying constraints. For example, you can=E2=80=99t extend a final c=
lass, even if you think that you have good reason for it, like constructing=
 a mock object.</div></blockquote><div><br></div><div><br></div><div>That&#=
39;s not strictness when the root concept is already filled with conceptual=
 holes...=C2=A0I&#39;m surprised=C2=A0nobody ever proposed the concept of a=
n *immutable* keyword, that&#39;d be like readonly but that&#39;d accept on=
ly also-immutable values. Until this happens, using readonly for that is a=
=C2=A0fallacy I&#39;m sorry... To me that invalidates all related arguments=
.</div><div><br></div><div>Nicolas</div></div></div>

--000000000000b4b01906397d881b--