Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123480
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-491-g033e30d24-fm-20240520.001-g033e30d2
Precedence: bulk
MIME-Version: 1.0
Message-ID: <89b695d7-661f-4c1b-ac4c-4480ad158e83@app.fastmail.com>
In-Reply-To: <A87ABAAF-E8DE-4417-BF96-19268CD7F668@gmail.com>
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <CAAwdEzB0rFhrai8W+B3PhnYEoOR-QEZYUm=R9+8+18Yo9WOgyQ@mail.gmail.com>
 <aadcd4ed-5f73-fbb9-93fb-42f2710e61fe@php.net>
 <ED20EE91-9BBB-4FED-8440-BAE748CBF5AB@gmail.com>
 <CAAwdEzBrRJMBQbY0R1Tp8RWpUP_DW6twNvGqnKDp3jjbiBFE-Q@mail.gmail.com>
 <734bb8e8-2fdf-4e50-9039-e53c99ee4930@app.fastmail.com>
 <A87ABAAF-E8DE-4417-BF96-19268CD7F668@gmail.com>
Date: Fri, 31 May 2024 20:59:51 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, May 31, 2024, at 5:45 PM, Claude Pache wrote:
>> Le 31 mai 2024 =C3=A0 18:08, Larry Garfield <larry@garfieldtech.com> =
a =C3=A9crit :
>>=20
>> However, this also brings up another interesting issue: readonly prop=
erties (in 8.3) DO allow redeclaration, essentially adjusting the proper=
ty scope (the class that declares it) to make the visibility check pass.=
 That is, the definition of the class it is private to changes, which is=
 different from how inheritance works elsewhere.  When the parent writes=
 to the same property, a special check is needed to verify the two prope=
rties are related.  All that special casing effectively means that reado=
nly in 8.4 wouldn't really be "write once + private(set)", but "write on=
ce + private(set) - final", which is... just kinda screwy.  That means o=
ur options are:
>>=20
>> * A BC break on readonly (not allowing it to be overridden)
>> * Make readonly an exception to the implicit final.
>> * Just don't allow readonly with aviz after all.
>
> Another possible option is:
>
> * Make readonly be `protected(set)` by default.
>
> That would weaken the originally intended semantics of readonly, but i=
n=20
> a compatible and acceptable way?
>
> =E2=80=94Claude

Only sort of compatible.  It would allow readonly props to be redefined,=
 and wouldn't break any existing code, I think... but it would mean any =
time you use readonly, suddenly a child class can come along and mess wi=
th it out from under you.

In practice that's likely not a common concern, but it is a behavior cha=
nge.  I think it's possible (I need to confirm with Ilija), if we want t=
hat slight BC break, but I don't know if we do.

--Larry Garfield