Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124770
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 05 Aug 2024 10:36:39 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <01ebb534-2b0c-4e5f-b4d4-a5f81b2db798@app.fastmail.com>
In-Reply-To: 
 <PH7PR16MB5781388723D03C148745639CDEBE2@PH7PR16MB5781.namprd16.prod.outlook.com>
References: <bf5f3563-46a8-46d0-bcce-307272e1c5fb@app.fastmail.com>
 <PH7PR16MB5781388723D03C148745639CDEBE2@PH7PR16MB5781.namprd16.prod.outlook.com>
Subject: Re: [PHP-DEV] [Vote] Asymmetric visibility v2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Aug 5, 2024, at 8:49 AM, Theodore Brown wrote:
> On Fri, July 26, 2024 at 12:25 Larry Garfield wrote:
>
>> Voting for Asymmetric Visibility is now open.
>>
>> https://wiki.php.net/rfc/asymmetric-visibility-v2
>
> Hi Larry and Ilija,
>
> Thank you for all your work on this RFC!
>
> One part that doesn't make sense to me is this sentence near the end in 
> the "Readonly is incompatible with inheritance" section:
>
>> With asymmetric visibility, the `readonly` usage here can be replaced with `protected protected(set)` or `readonly protected protected(set)`, avoiding the need to double-declare properties.
>
> `protected protected(set)` just removes readonly, and is the same as 
> `protected`, right? So couldn't such a change be done now without 
> asymmetric visibility?
>
> And the change to `protected protected(set) readonly` as shown in the 
> example also seems unnecessary, since earlier in the RFC it says that 
> readonly will be changed to imply `protected(set)` rather than 
> `private(set)`. So it seems that no change is needed to the abstract 
> class here - the properties can remain `protected readonly`, and the 
> implementation can be simplified since readonly properties will now 
> imply `protected(set)`.
>
> Or have I misunderstood something here?

I believe in this case you're correct.  That example was written early on, before we decided to expand readonly to protected(set) by default.  I didn't realize that needed to be updated as well.  Yes, in this case, the widening of readonly would also resolve that issue.  `protected protected(set)` would now be redundant, but not hurt anything, whereas `protected private(set)` would have an effect.  `public public(set) readonly` would also be legal (though I don't personally know why you'd do that, there's no inherent reason to make it illegal).

--Larry Garfield