Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126512
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 26 Feb 2025 14:02:00 +0100
To: internals@lists.php.net
Message-ID: <bea55dd8-61c7-42eb-af0b-8d6f19895daa@app.fastmail.com>
In-Reply-To: <1EBBCAA7-AC32-4C2F-8EB3-B1A69E1D1783@rwec.co.uk>
References: <0b408765-04c4-49ed-bd5a-bceb34a2a3f1@app.fastmail.com>
 <f8702afc-6212-4a0f-8097-652f27194795@rwec.co.uk>
 <e8396080-70a0-4220-9f17-73d8222f56ad@app.fastmail.com>
 <1EBBCAA7-AC32-4C2F-8EB3-B1A69E1D1783@rwec.co.uk>
Subject: Re: [PHP-DEV] Consensus gathering: allowing unsetting of backed property hooks
Content-Type: multipart/alternative;
 boundary=13fc90f226324608ae6f8a91be0ebeb9
From: rob@bottled.codes ("Rob Landers")

--13fc90f226324608ae6f8a91be0ebeb9
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 26, 2025, at 09:17, Rowan Tommins [IMSoP] wrote:
>=20
>=20
> On 25 February 2025 23:31:25 GMT, tight.fork3192@fastmail.com wrote:
> >On 2/25/25 4:51 PM, Rowan Tommins [IMSoP] wrote:
> >> I actually started writing an RFC to rationalise some of this behav=
iour
> >
> >I'm glad I'm not the only one who considers this an issue worth pursu=
ing!
>=20
> Sorry, I wasn't clear: I was looking at the existing typed vs untyped,=
 unrefined vs uninitialised mess, before property hooks even existed.
>=20
>=20
> >
> >> Here are some of the things that might happen as a result of unset(=
$foo->bar):
> >
> >I don't disagree that there's a lot of weirdness. But for better or w=
orse that's where PHP is now - it's a fundamentally weird language. I th=
ink it's better to be consistently weird than to be inconsistently weird.
>=20
> My point is that it's *already* inconsistently weird.
>=20
>=20
> > It would be inconsistent to allow unsetting some types of properties=
 but not others, and which ones can and can't be unset are indistinguish=
able to a 3rd-party consumer.
>=20
> unset() can already have a bunch of different effects depending on the=
 implementation of the class. As well as __unset being able to do *absol=
utely anything*, I missed from my list "readonly" properties, which reas=
onably enough *always throw an error for unset*, just like hooked proper=
ties.
>=20
>=20
> >I can't comment from an implementation perspective, but as a user of =
PHP I would expect unsetting a backed property to return the property th=
e "uninitialized" state, and subsequent access would proceed as if it we=
re the first access of the uninitialized property.
>=20
> An untyped property is currently never in the "uninitialised" state, o=
nly a different "undefined" state. Presumably this inconsistency would n=
eed to be preserved (for consistency)
>=20
>=20
> >Unsetting a virtual property could simply do nothing, but not result =
in a fatal error. I don't think a warning is even necessary because no a=
ction is taken.
>=20
> I don't see how that would be useful. The user presumably expected it =
to do *something*, so informing them that it didn't seems preferable to =
silently ignoring their request. It would also be inconsistent: a virtua=
l property with no "set" hook throws an error when you try to set it, it=
 doesn't silently discard the value.
>=20
>=20
>=20
> > I certainly don't want to be required to define an unset hook for ev=
ery single backed property; rather `unset()` should have a default behav=
ior.
>=20
> I think you're focusing too closely on one use case, rather than all t=
he ways people will want to use hooked properties. Imagine you have two =
properties which you want to keep in sync: setting either of them recalc=
ulates the other, using set hooks.
>=20
> * It would be really surprising to the class author if a user of the c=
lass could "reach in" and invalidate the state by calling unset() on one=
 of the properties.
> * It would be really surprising to the user if doing so worked on one =
of the properties, but silently did nothing on the other because it was =
implemented as virtual.
> * It might be appropriate for the class author to add "unset" hooks to=
 both properties, and for the user to see that unsetting one unset the o=
ther, just as setting one sets the other.
>=20
> That's just one scenario, I'm sure there are others where you could pi=
cture different expectations, particularly accounting for some of the ot=
her behaviour of unset(). That's what I mean by it being hard to specify=
 the behaviour; nothing to do with the implementation.
>=20
> Regards,
> Rowan Tommins
> [IMSoP]

I do think it makes sense to have an unset hook though, so long as it is=
 thought out well. For example, would the unset hook be called automatic=
ally during garbage collection? Is it only called via unset() or are the=
re other cases where it could be called too?

Regardless of how wise it is to unset from outside a class, doing the su=
ggested workaround from inside the class seems a bit odd as well.

=E2=80=94 Rob
--13fc90f226324608ae6f8a91be0ebeb9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Wed, Feb 26,=
 2025, at 09:17, Rowan Tommins [IMSoP] wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div><br></div><div><br></div><div>On 25 Feb=
ruary 2025 23:31:25 GMT,&nbsp;<a href=3D"mailto:tight.fork3192@fastmail.=
com">tight.fork3192@fastmail.com</a> wrote:<br></div><div>&gt;On 2/25/25=
 4:51 PM, Rowan Tommins [IMSoP] wrote:<br></div><div>&gt;&gt; I actually=
 started writing an RFC to rationalise some of this behaviour<br></div><=
div>&gt;<br></div><div>&gt;I'm glad I'm not the only one who considers t=
his an issue worth pursuing!<br></div><div><br></div><div>Sorry, I wasn'=
t clear: I was looking at the existing typed vs untyped, unrefined vs un=
initialised mess, before property hooks even existed.<br></div><div><br>=
</div><div><br></div><div>&gt;<br></div><div>&gt;&gt; Here are some of t=
he things that might happen as a result of unset($foo-&gt;bar):<br></div=
><div>&gt;<br></div><div>&gt;I don't disagree that there's a lot of weir=
dness. But for better or worse that's where PHP is now - it's a fundamen=
tally weird language. I think it's better to be consistently weird than =
to be inconsistently weird.<br></div><div><br></div><div>My point is tha=
t it's *already* inconsistently weird.<br></div><div><br></div><div><br>=
</div><div>&gt; It would be inconsistent to allow unsetting some types o=
f properties but not others, and which ones can and can't be unset are i=
ndistinguishable to a 3rd-party consumer.<br></div><div><br></div><div>u=
nset() can already have a bunch of different effects depending on the im=
plementation of the class. As well as __unset being able to do *absolute=
ly anything*, I missed from my list "readonly" properties, which reasona=
bly enough *always throw an error for unset*, just like hooked propertie=
s.<br></div><div><br></div><div><br></div><div>&gt;I can't comment from =
an implementation perspective, but as a user of PHP I would expect unset=
ting a backed property to return the property the "uninitialized" state,=
 and subsequent access would proceed as if it were the first access of t=
he uninitialized property.<br></div><div><br></div><div>An untyped prope=
rty is currently never in the "uninitialised" state, only a different "u=
ndefined" state. Presumably this inconsistency would need to be preserve=
d (for consistency)<br></div><div><br></div><div><br></div><div>&gt;Unse=
tting a virtual property could simply do nothing, but not result in a fa=
tal error. I don't think a warning is even necessary because no action i=
s taken.<br></div><div><br></div><div>I don't see how that would be usef=
ul. The user presumably expected it to do *something*, so informing them=
 that it didn't seems preferable to silently ignoring their request. It =
would also be inconsistent: a virtual property with no "set" hook throws=
 an error when you try to set it, it doesn't silently discard the value.=
<br></div><div><br></div><div><br></div><div><br></div><div>&gt; I certa=
inly don't want to be required to define an unset hook for every single =
backed property; rather `unset()` should have a default behavior.<br></d=
iv><div><br></div><div>I think you're focusing too closely on one use ca=
se, rather than all the ways people will want to use hooked properties. =
Imagine you have two properties which you want to keep in sync: setting =
either of them recalculates the other, using set hooks.<br></div><div><b=
r></div><div>* It would be really surprising to the class author if a us=
er of the class could "reach in" and invalidate the state by calling uns=
et() on one of the properties.<br></div><div>* It would be really surpri=
sing to the user if doing so worked on one of the properties, but silent=
ly did nothing on the other because it was implemented as virtual.<br></=
div><div>* It might be appropriate for the class author to add "unset" h=
ooks to both properties, and for the user to see that unsetting one unse=
t the other, just as setting one sets the other.<br></div><div><br></div=
><div>That's just one scenario, I'm sure there are others where you coul=
d picture different expectations, particularly accounting for some of th=
e other behaviour of unset(). That's what I mean by it being hard to spe=
cify the behaviour; nothing to do with the implementation.<br></div><div=
><br></div><div>Regards,<br></div><div>Rowan Tommins<br></div><div>[IMSo=
P]<br></div></blockquote><div><br></div><div>I do think it makes sense t=
o have an unset hook though, so long as it is thought out well. For exam=
ple, would the unset hook be called automatically during garbage collect=
ion? Is it only called via unset() or are there other cases where it cou=
ld be called too?<br></div><div><br></div><div>Regardless of how wise it=
 is to unset from outside a class, doing the suggested workaround from i=
nside the class seems a bit odd as well.</div><div><br></div><div id=3D"=
sig121229152">=E2=80=94 Rob<br></div></body></html>
--13fc90f226324608ae6f8a91be0ebeb9--