Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119006
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <9AB678BC-ACF1-47F0-92A2-6F47AA1CEDBE@gmail.com>
Date: Mon, 14 Nov 2022 21:02:50 +0100
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <EB7D00D3-54C7-4AD9-9DF1-B3ABFFF6B6B7@gmail.com>
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
 <9AB678BC-ACF1-47F0-92A2-6F47AA1CEDBE@gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: claude.pache@gmail.com (Claude Pache)



>>=20
>> 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.
>=20
> I think that Option 1 is the most reasonable. The meaning of `public =
public(set)` and `protected protected(set)` is straightforward; from a =
user point-of-view, disallowing them seems more like =E2=80=9Cit is =
useless=E2=80=9D than =E2=80=9Cit is confusing=E2=80=9D. Unless there =
are good technical reason to restrict it, we can just leave to linting =
tools the care of reporting it.
>=20
> =E2=80=94Claude
>=20

To clarify my position:

* The set visibility must be either more restrictive or of the same =
restriction level than the get visibility.

* When the set visibility is absent, it is inferred as following:
     * If `readonly` is present, the set visibility is `private` (as of =
today);
     * otherwise, the set visibility is the same as the get visibility =
(again, as of today).

* We don=E2=80=99t judge whether it is reasonable to write `protected =
protected(set) string $foo;` when you could just write `protected string =
$foo` for the same effect. Similarly, we don=E2=80=99t judge whether it =
is reasonable to write `public function()` when you could just write =
`function()` for the same effect. We leave it to coding styles and =
linters to decide whether the short form or the long form is preferred.

=E2=80=94Claude