Re: Re: [RFC][Discussion] Har monise "untyped" and "typed" properties

On 22 November 2023 14:12:09 GMT, Nicolas Grekas <nicolas.grekas+php@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]