Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119053
Message-ID: <434BDABD-8551-46C8-98EC-8CA87952AE25@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C3FAE96F-B3F0-47D5-B2CF-96A6DEEEE21F"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Wed, 30 Nov 2022 00:46:51 +0100
In-Reply-To: <831b9906-dc0c-420c-b22f-8a0cc8a1ad64@app.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
 <831b9906-dc0c-420c-b22f-8a0cc8a1ad64@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: claude.pache@gmail.com (Claude Pache)

--Apple-Mail=_C3FAE96F-B3F0-47D5-B2CF-96A6DEEEE21F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 29 nov. 2022 =C3=A0 21:29, Larry Garfield <larry@garfieldtech.com> =
a =C3=A9crit :
>=20
>=20
> Thank you everyone for the feedback.  Based on this thread, we've made =
two changes to the RFC:
>=20
> 1. We've moved readonly back to forbidden with a-viz for now.  I've =
added a section to Future Scope where we really should sort this out in =
the future, but we'll do that in the future when we can all focus on the =
various nuances of just that piece.
>=20
> 2. I rewrote the section on __set to make it clearer.  That also =
included Ilija and I digging into all the nuances that are already =
present.  The text may still look a bit complex, but that's because the =
existing logic is already complex with readonly.  Long story short, the =
a-viz RFC does not change anything in the way __set works vis a vis =
asymmetric visibility; it just inherits and continues what readonly =
already started, so it's consistent.
>=20
> The PR should be updated in the next week or two with the latest =
changes.  Baring any major need for change, we expect to call a vote for =
it shortly after New Years.
>=20
> Thanks all.
>=20
> --Larry Garfield
>=20

Hi,

In the RFC, section Permitted visibility =
(https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility =
<https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility>):
> The set visibility, if it differs from the main (get) visibility, MUST =
be strictly lesser than the main visibility. That is, the set visibility =
may only be protected or private. If the main visibility is protected, =
set visibility may only be private. Any violation of this rule will =
result in a compile time error.
>=20
The first sentence does not forbid `public public(set)`, or `protected =
protected(set)`, etc. (the `set` visibility does not differ from the =
main visibility), but the rest of the paragraph does not allow it. That =
should be clarified.

(Because forbidding `public public(set)`, etc., makes it slightly more =
cumbersome to explain the rules, I am slightly in favour not to forbid =
it.)

> There is one exception, that of a private readonly property. That =
would technically expand to private private(set) readonly, which is =
allowed.

That sentence should be deleted, as `readonly` is now forbidden.

=E2=80=94Claude=

--Apple-Mail=_C3FAE96F-B3F0-47D5-B2CF-96A6DEEEE21F--