On Mon, 14 Nov 2022, Ilija Tovilo wrote: > Hi Derick > > > > As I understand it, you’re suggesting that a property declared as > > > `public protected(set)` would never trigger __set(). > > > > I would think that that would be against our current practice, which is > > easy enough to explain as "if the property isn't visible set, > > then use __set()". I would argue that "protected(set)" marks a property > > as invisible from a non-inherited class/method, and hence __set should > > be called. > > What you're describing does not match the readonly behavior. > https://3v4l.org/X76pV > > Readonly properties only call __set once they are explicitly unset. > The same applies to __unset. I changed this in the asymmetric > visibility implementation recently to match this behavior but the RFC > has not been adjusted to reflect this yet. > > AFAIK this behavior is there to allow calls to __set for certain edge > cases. While not very intuitive it makes sense to stay consistent. If > this behavior is undesirable we should change it in both places.
Now I have re-read the Assymetric Visibility RFC's "Interaction with __set" (https://wiki.php.net/rfc/asymmetric-visibility#interaction_with_set), I'm slightly more confused. Could you update that section, as what it currently states seems reasonable. cheers, Derick
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
