Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118997
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
Mime-Version: 1.0
Message-ID: <a1382087-69c6-4c43-acb0-cda32a9ed9d7@app.fastmail.com>
In-Reply-To: 
 <CADK1yXJkJY57qbmqkHc55S2TyoaxGBt-jN5dPkj8eHv_EGYGrA@mail.gmail.com>
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
 <CADK1yXJkJY57qbmqkHc55S2TyoaxGBt-jN5dPkj8eHv_EGYGrA@mail.gmail.com>
Date: Sun, 13 Nov 2022 15:57:20 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Nov 13, 2022, at 3:50 PM, Deleu wrote:
>>
>>
>> 2. `readonly` is a "write once" flag that may be combined with asymmetric
>> visibility.  If no set visibility is specified, `readoly` implies
>> `private(set)`, but a different set visibility may also be provided.
>>
>> These are both reasonable rules.  However, it creates a conflict.
>> Specifically, in the following cases:
>>
>> public public(set) readonly string $foo
>>
>> protected protected(set) readonly string $foo
>>
>
> What if the implicit rule for `readonly` is changed into `protected(set)`?
> Let's run with this for a minute.
>
> 1- It's not truly a CODE breaking change. Right now if you have a
> `protected readonly` property, you're either calling the parent constructor
> or you're never making use of the variable, otherwise you're getting a
> Fatal Error.

This is untrue.  You can declare a private property identically in a parent and child class, even readonly.  I'm doing this now in a project.  It works, but would be unnecessary if the parent's property were protected(set).

--Larry Garfield