Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124550
Message-ID: <e6ea3c7c-ccfe-4dca-94ff-3929223832e6@bastelstu.be>
Date: Mon, 22 Jul 2024 21:07:15 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <b5c0be62-ea39-47fb-a8f8-ab6cd5ee3dab@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <b5c0be62-ea39-47fb-a8f8-ab6cd5ee3dab@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 7/20/24 03:14, Larry Garfield wrote:
> Baring any new developments, we plan to start the vote early next week.

I've went through the RFC once more. I have the following remarks:

> For that reason, a private(set) property is automatically final and may not be redeclared at all.
> 

I assume that explicitly marking it as final is still allowed (just 
redundant)?

> There is one caveat regarding virtual properties that have no set operation. If there is no set operation defined on a property, then it is nonsensical to specify a visibility for it. That case will trigger a compile error. For example:
> 

How does this interact with inheritance? Consider the following example:

     class P {
         public $answer { get => 42; }
     }

     class C extends P {
         public protected(set) $answer { get => 42; set => 'dummy'; }
     }

This could be considered to be both narrowing the `set` visibility from 
`public` to `protected` (which is unsound), but also widening it from 
“never” to `protected` (which would be sound).

> as it's possible now for a property to be visible but not writeable. For the time being,

I dislike the “for the time being” phrasing, because changing that would 
effectively result in a breaking change, because the __set() may be 
called in situations that were not anticipated. I would have preferred a 
stronger phrasing that makes it clear that the RFC authors know what 
they are talking about.

Best regards
Tim Düsterhus