Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124187
Message-ID: <8A3C2FDA-60DF-45A1-BA9D-11B6FB6F755C@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_09A7916A-1638-4A30-89F5-51D67FB372C1"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: Re: [PHP-DEV] [RFC] Property Hook improvements
Date: Wed, 3 Jul 2024 11:54:58 +0200
In-Reply-To: <fbf45a9a-0385-4c42-a6a0-4f3ee1c8728d@app.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
References: <fbf45a9a-0385-4c42-a6a0-4f3ee1c8728d@app.fastmail.com>
From: claude.pache@gmail.com (Claude Pache)


--Apple-Mail=_09A7916A-1638-4A30-89F5-51D67FB372C1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 1 juil. 2024 =C3=A0 19:02, Larry Garfield <larry@garfieldtech.com> =
a =C3=A9crit :
>=20
> Hi folks.  As Ilija's been polishing off hooks to get the PR merged, =
we've run into two small revisions that should make life better for all =
involved.  One is a performance improvement that requires a very slight =
error handling behavior change, and the other is enabling readonly in =
selected (but probably all of the relevant) circumstances.
>=20
> I'd say we expect these to be uncontroversial, but this is PHP. :-)  =
So I will instead just note that it's a short RFC and open the =
discussion accordingly.
>=20
> https://wiki.php.net/rfc/hook_improvements
>=20
> --=20
>  Larry Garfield
>  larry@garfieldtech.com

Hi,

1. Removing the guard against recursion is sensible to me, as the sort =
of bug it is supposed to prevent is not specific to property accessors. =
IMO, a better solution to the issue is to implement a global upper limit =
on the call stack size. Currently, I am able to generate a call stack of =
more than 10 millions items before an OOM error occurs; PHP should have =
thrown a stack overflow error long before that. But this is entirely =
orthogonal to property hooks.

2. As for readonly, I think that the invariant it is supposed to provide =
should be enforced as strictly as possible. It means that `readonly` is =
only acceptable if there is no `get` hook.

The primary reason I would want readonly with `get` hook, is lazy =
initialisation, and I think that there is better design than to trust =
the user for not implementing bugs. For that use case, I think it is =
preferable to implement dedicated hook for lazy initialisation, =
orthogonal to the readonly feature. Here is what I would suggest (in a =
separate RFC, of course):

* An additional hook, called `init`, may be added to backed properties. =
When attempting to read the value of the backing store, if it is =
uninitialised, then the `init` hook is triggered, which is supposed to =
initialise it.

In general, a hooked property can be marked as `readonly` when it is =
backed and has no `get` hook. In particular, it can have an `init` hook, =
which is all we need in order to have a lazy readonly property that is =
robust against bugs by construction.

=E2=80=94Claude



--Apple-Mail=_09A7916A-1638-4A30-89F5-51D67FB372C1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>Le 1 juil. 2024 =C3=A0 19:02, Larry Garfield =
&lt;larry@garfieldtech.com&gt; a =C3=A9crit :</div><br =
class=3D"Apple-interchange-newline"><div><div>Hi folks. &nbsp;As Ilija's =
been polishing off hooks to get the PR merged, we've run into two small =
revisions that should make life better for all involved. &nbsp;One is a =
performance improvement that requires a very slight error handling =
behavior change, and the other is enabling readonly in selected (but =
probably all of the relevant) circumstances.<br><br>I'd say we expect =
these to be uncontroversial, but this is PHP. :-) &nbsp;So I will =
instead just note that it's a short RFC and open the discussion =
accordingly.<br><br>https://wiki.php.net/rfc/hook_improvements<br><br>-- =
<br> &nbsp;Larry Garfield<br> =
&nbsp;larry@garfieldtech.com<br></div></div></blockquote></div><br><div>Hi=
,</div><div><br></div><div><div>1. Removing the guard against recursion =
is sensible to me, as the sort of bug it is supposed to prevent is not =
specific to property accessors. IMO, a better solution to the issue is =
to implement a global upper limit on the call stack size. Currently, I =
am able to generate a call stack of more than 10 millions items before =
an OOM error occurs; PHP should have thrown a stack overflow error long =
before that. But this is entirely orthogonal to property =
hooks.</div><div><br></div><div>2. As for readonly, I think that the =
invariant it is supposed to provide should be enforced as strictly as =
possible. It means that `readonly` is only acceptable if there is no =
`get` hook<span style=3D"font-size: =
13px;">.</span></div><div><br></div><div>The primary reason I would want =
readonly with `get` hook, is lazy initialisation, and I think that there =
is better design than to trust the user for not implementing bugs. For =
that use case, I think it is preferable to implement dedicated hook for =
lazy initialisation, orthogonal to the readonly feature. Here is what I =
would suggest (in a separate RFC, of course):</div><div><br></div><div>* =
An additional hook, called `init`, may be added to backed properties. =
When attempting to read the value of the backing store, if it is =
uninitialised, then the `init` hook is triggered, which is supposed to =
initialise it.</div><div><br></div><div>In general, a hooked property =
can be marked as `readonly` when it is backed and has no `get` hook. In =
particular, it can have an `init` hook, which is all we need in order to =
have a lazy readonly property that is robust against bugs by =
construction.</div><div><br></div><div>=E2=80=94Claude</div><div><br></div=
><br class=3D"Apple-interchange-newline"></div></body></html>=

--Apple-Mail=_09A7916A-1638-4A30-89F5-51D67FB372C1--