Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119002
Date: Mon, 14 Nov 2022 11:28:13 +0000 (GMT)
To: Larry Garfield <larry@garfieldtech.com>
cc: php internals <internals@lists.php.net>
In-Reply-To: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
Message-ID: <alpine.DEB.2.23.453.2211141124170.1167818@singlemalt.home.derickrethans.nl>
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
User-Agent: Alpine 2.23 (DEB 453 2020-06-18)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: derick@php.net (Derick Rethans)

On Sun, 13 Nov 2022, Larry Garfield wrote:

> There's two design decisions we've made at this point, both of which 
> we think are logical and reasonable:
> 
> 1. If specified, the set visibility must be tighter than the get 
> visibility.  So `protected protected(set)` and `protected public(set)` 
> are not permitted, for instance.
> 
> 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

Just to see if I understand this correctly, the "protected(set)" 
overwrites the implicit "private(set)" that "readonly" confers?

I think that alone is confusing.

> These would be the only way to have a non-private-set readonly 
> property.  While the first is in practice quite unlikely, the second 
> has valid use cases.  (In particular, a base class that provides 
> properties expected to be set by a child constructor, and then used by 
> a method in the parent class.)  However, it would not be allowed under 
> the rules above.  Working around it would require specifying `public 
> protected(set) readonly...`, which means exposing a property that 
> likely should not be exposed.
> 
> That creates an odd situation where readonly and asymmetric visibility 
> may only be combined "sometimes."  That is not deesireable.  The only 
> way to combine them in their current form is to allow `protected 
> protected(set)` only if readonly is in use, which is excessively 
> complicated both to implement and to explain/document/use.
> 
> We see two possible ways to resolve this conflict:
> 
> 1. Relax the set-is-tighter restriction.  That would allow `protected 
> protected(set)` etc. on any property.  It wouldn't be particularly 
> useful unless readonly is being used, but it would be syntactically 
> legal and behave as you'd expect.  We could still disallow "set is 
> more permissive" combinations (eg, `private public(set)`), as those 
> have no apparent use case.
> 
> 2. Disallow readonly and asymmetric visibility being combined, because 
> readonly already has a hard-coded implied asymmetric visibility.  
> This option removes some potential use cases (they would most likely 
> drop the readonly), but has the upside that it's easier to re-allow at 
> some point in the future.

I am in favour of this option 2. As I already think "protected 
protected(set) readonly" is a confusing thing to see. If I hadn't read 
this email, I wouldn't have understood the interacting between the 
"protected(set)" and "readonly".

cheers,
Derick