Re: [RFC] Asymmetric Visibility, with readonly
| From: | Deleu | Date: | Sun, 13 Nov 2022 22:48:22 +0000 |
| Subject: | Re: [RFC] Asymmetric Visibility, with readonly | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118999@lists.php.net to get a copy of this message | ||
On Sun, Nov 13, 2022 at 5:09 PM Larry Garfield <larry@garfieldtech.com>
wrote:
> Hi folks. Ilija is nearly done with the implementation for asymmetric
> visibility and flushing out edge cases, but we've run into one design
> question we'd like feedback on.
>
> 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:
>
To unsubscribe, visit: https://www.php.net/unsub.php
>
>
The more I think about this, the more it makes more sense (to me) to
simplify it even further;
1) The set visibility should be the same as the get visibility when one is
not provided. That is:
```
public $var -> public public(set) $var
protected $var -> protected protected(set) $var
private $var -> private private(set) $var
```
The explicit declaration of same visibility can be disallowed e.g. `public
public(set) $var is not allowed, you must use public $var` if you want
visibility symmetry. However, if it simplifies implementation to allow it,
why not? The behavior would already be in place anyway.
2) The readonly flag should no longer have an impact on the set visibility.
This is again a conceptual breaking change, but one that can even be fixed
with a SEARCH/REPLACE on a project scope. The "breaking change" is
categorized as follows:
The code public readonly $var used to be `public private(set) readonly
$var should become public public(set) readonly $var`
The code protected readonly $var used to be `protected private(set)
readonly $var should become protected protected(set) readonly $var`
The code private readonly $var should not have any change.
--
Marco Deleu