On 08/08/2022 10:09, Stephen Reay wrote:
The RFC states that it’s to keep consistency with `readonly`, because __set on a readonly property that’s initialised throws an error - but isn’t that because of the nature of it being readonly, rather than because of the visibility rules? The error given is "Cannot modify readonly property” thrown from within the __set() method, not "Cannot access protected property” thrown from the outside calling context, when the __set() method is not implemented.
If a property is "public readonly", the __set method is never called if you try to reassign it: https://3v4l.org/8PioE The proposal is that the same applies if it is "public private(set)": the assignment immediately fails, rather than falling back to the __set method.
The logic, I think, is that a completely private property is "invisible", so __set acts like it doesn't exist at all and runs *instead of* the assignment; but a "public readonly" or "public private(set)" property is "visible", so the assignment is attempted and fails.
However, I am concerned that the rules around where __set and __get are called are becoming increasingly complex with a lot of different concepts interacting - "declared", "defined", "typed", "initialized", "visible", "modifiable", etc.
As I mentioned in a previous discussion, I think we need to work towards simplifying this - e.g. merge "typed" and "untyped" properties by making "public $foo" equivalent to "public mixed $foo", which would remove the distinction between "defined" and "initialized".
Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
