Re: [RFC] Asymmetric visibility

> On 8 Aug 2022, at 20:21, Rowan Tommins <rowan.collins@gmail.com> wrote: > > 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 > Hi Rowan, Thanks for trying to explain the logic here. @Larry is Rowan’s assessment accurate? Cheers Stephen