Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118999
MIME-Version: 1.0
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
In-Reply-To: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
Date: Sun, 13 Nov 2022 19:48:22 -0300
Message-ID: <CADK1yXKJhopCrk3ssBCnsAqFGUokOsOPA6scbxfPQt5hHzbwig@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b486d405ed61ed23"
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: deleugyn@gmail.com (Deleu)

--000000000000b486d405ed61ed23
Content-Type: text/plain; charset="UTF-8"

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

--000000000000b486d405ed61ed23--