Hi Stephen > So here’s my last attempt: > > Please change this behaviour in your rfc. > > You are explicitly making it mutually exclusive with readonly now, so that’s > not a bc break - if/when it becomes compatible with readonly the authors of > that rfc can either keep the limitation as it exists **for readonly > properties** (I’m not an expert but I don’t believe this would be a BC break > either), or decide to drop the limitation completely (deliberate BC break) > > Keeping the limitation now on non-readonly properties makes no sense, and > will be confusing to user land developers.
This behavior is already not limited to readonly, it works the same for normal typed properties. https://3v4l.org/WpBp4 The set-visibility is not relevant here: When unset has been called, __set will be called (and __get too). The set-visibility is only relevant when unset hasn't been called, as that will influence whether the property is written to or an error is thrown. The RFC is actually wrong saying this is specifically due to readonly properties. This behavior has been here for a while. See the relevant commit: https://github.com/php/php-src/commit/f1848a4b3f807d21415c5a334b461d240b2a83af > Assigning to an uninitialized typed property will no longer trigger > a call to __set(). However, calls to __set() are still triggered if > the property is explicitly unset(). > This gives us both the behavior people generally expect, and still > allows ORMs to do lazy initialization by unsetting properties. > For PHP 8, we should fine a way to forbid unsetting of declared > properties entirely, and provide a different way to achieve lazy > initialization. I'm not sure if anybody actually makes use of this trick. It might be worth removing this weird behavior by offering an alternative. In any case, this is out of scope for this RFC. Regards, Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
