Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118389
Message-ID: <b3688412-a75a-2a65-1e05-41c8b4b30de6@gmail.com>
Date: Mon, 8 Aug 2022 14:21:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.12.0
Content-Language: en-GB
To: internals@lists.php.net
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
 <C7124120-30F1-4D4F-8569-C928AC63B999@koalephant.com>
In-Reply-To: <C7124120-30F1-4D4F-8569-C928AC63B999@koalephant.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility
From: rowan.collins@gmail.com (Rowan Tommins)

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]