Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126511
Feedback-ID: id5114917:Fastmail
Date: Wed, 26 Feb 2025 08:17:46 +0000
To: internals@lists.php.net
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_Consensus_gathering=3A_allo?=
 =?US-ASCII?Q?wing_unsetting_of_backed_property_hooks?=
User-Agent: K-9 Mail for Android
In-Reply-To: <e8396080-70a0-4220-9f17-73d8222f56ad@app.fastmail.com>
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>
Message-ID: <1EBBCAA7-AC32-4C2F-8EB3-B1A69E1D1783@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 25 February 2025 23:31:25 GMT, tight=2Efork3192@fastmail=2Ecom wrote:
>On 2/25/25 4:51 PM, Rowan Tommins [IMSoP] wrote:
>> I actually started writing an RFC to rationalise some of this behaviour
>
>I'm glad I'm not the only one who considers this an issue worth pursuing!

Sorry, I wasn't clear: I was looking at the existing typed vs untyped, unr=
efined vs uninitialised mess, before property hooks even existed=2E


>
>> 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=2E But for better or wor=
se that's where PHP is now - it's a fundamentally weird language=2E I think=
 it's better to be consistently weird than to be inconsistently weird=2E

My point is that it's *already* inconsistently weird=2E


> It would be inconsistent to allow unsetting some types of properties but=
 not others, and which ones can and can't be unset are indistinguishable to=
 a 3rd-party consumer=2E

unset() can already have a bunch of different effects depending on the imp=
lementation of the class=2E As well as __unset being able to do *absolutely=
 anything*, I missed from my list "readonly" properties, which reasonably e=
nough *always throw an error for unset*, just like hooked properties=2E


>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 the "unin=
itialized" state, and subsequent access would proceed as if it were the fir=
st access of the uninitialized property=2E

An untyped property is currently never in the "uninitialised" state, only =
a different "undefined" state=2E Presumably this inconsistency would need t=
o be preserved (for consistency)


>Unsetting a virtual property could simply do nothing, but not result in a=
 fatal error=2E I don't think a warning is even necessary because no action=
 is taken=2E

I don't see how that would be useful=2E The user presumably expected it to=
 do *something*, so informing them that it didn't seems preferable to silen=
tly ignoring their request=2E It would also be inconsistent: a virtual prop=
erty with no "set" hook throws an error when you try to set it, it doesn't =
silently discard the value=2E



> I certainly don't want to be required to define an unset hook for every =
single backed property; rather `unset()` should have a default behavior=2E

I think you're focusing too closely on one use case, rather than all the w=
ays people will want to use hooked properties=2E Imagine you have two prope=
rties which you want to keep in sync: setting either of them recalculates t=
he other, using set hooks=2E

* It would be really surprising to the class author if a user of the class=
 could "reach in" and invalidate the state by calling unset() on one of the=
 properties=2E
* It would be really surprising to the user if doing so worked on one of t=
he properties, but silently did nothing on the other because it was impleme=
nted as virtual=2E
* It might be appropriate for the class author to add "unset" hooks to bot=
h properties, and for the user to see that unsetting one unset the other, j=
ust as setting one sets the other=2E

That's just one scenario, I'm sure there are others where you could pictur=
e different expectations, particularly accounting for some of the other beh=
aviour of unset()=2E That's what I mean by it being hard to specify the beh=
aviour; nothing to do with the implementation=2E

Regards,
Rowan Tommins
[IMSoP]