On 22 November 2023 14:12:09 GMT, Nicolas Grekas <nicolas.grekas+...@gmail.com>
wrote:
>I think there is an inaccuracy that needs to be fixed in the after-unset
>state : as noted later in the RFC, magic accessors are called after an
>unset($this->typedProps). This means the state cannot be described as
>identical ("uninitialized') before and after unset() in the first table in
>the RFC. Isn't there some vocabulary in the source that we can use to
>describe those states more accurately?
Oh. Wow. That's more than just inaccurate terminology...
I always assumed the rule was "access to uninitialised properties triggers
__get", not that there was yet another magical state buried in the
implementation. From a user point of view, I find that frankly terrible:
> Typed properties start off as uninitialized, but if you use unset(), you can
> make them *super-uninitialized*.
>
> There's no way to actually see if something's uninitialized or
> super-uninitialized; and once you've assigned a value, you can't go back to
> the original uninitialized, only to super-uninitialized.
>
> Accessing an uninitialized property always throws an error, whereas accessing
> a super-uninitialized property will first check for __get.
I'm not sure choosing a different name from "super-uninitialized" makes much
difference to how that reads.
I'm probably going to regret asking this, but is there some reason it works
that way? Is there any chance of changing it to just:
> Typed properties start off as uninitialized.
>
> Once you've assigned a value, you can't go back to the original uninitialized
> state using unset()
>
> Accessing an uninitialized property will first check for __get, and throw an
> error if that isn't defined.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
