Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123538
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-497-g97f96844c-fm-20240526.001-g97f96844
Precedence: bulk
MIME-Version: 1.0
Message-ID: <0b6d7308-3c32-477c-8bf2-e8e0880cbb05@app.fastmail.com>
In-Reply-To: 
 <CAL0xaBFSAp0ewzRyDmWBLwkbAus13LF7mKqW59QUd0x2c9jtkQ@mail.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>
 <89b695d7-661f-4c1b-ac4c-4480ad158e83@app.fastmail.com>
 <6d644f0f-cbeb-484c-b267-bf1d97e6d27a@app.fastmail.com>
 <10AAAA51-9538-4F97-83D1-91F154C745F7@gmail.com>
 <CAL0xaBFSAp0ewzRyDmWBLwkbAus13LF7mKqW59QUd0x2c9jtkQ@mail.gmail.com>
Date: Fri, 07 Jun 2024 14:28:56 +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 Wed, Jun 5, 2024, at 7:55 PM, Arvids Godjuks wrote:
> On Wed, 5 Jun 2024 at 19:59, Claude Pache <claude.pache@gmail.com> wro=
te:
>> *snip*
>> Hi Larry and Ilija,
>>=20
>> Thanks for your work. Here is my opinion:
>>=20
>> First, I do think that `readonly` should integrate with aviz, unless =
that implies truly controversial changes on `readonly`. As Theodore Brow=
n commented in the previous version of the RFC: =E2=80=9CProposal feels =
unfinished since it can't be used in conjunction with readonly propertie=
s/classes. In my opinion the issues with this need to be resolved first,=
 to avoid the language moving towards a messy hodgepodge of features tha=
t don't work well together.=E2=80=9D
>>=20
>> Second, I think that making `readonly` implicitly `protected(set)` by=
 default (Option 2) is the way to go:
>> * At first glance it is an expectation change. But, in reality, all r=
eadonly properties can *already* be written to from a child class as of =
today: it suffices that the child class in question redeclare those prop=
erties: https://3v4l.org/9AV4r. From the point of view of the child clas=
s, the only thing that will change, is that it will no longer be require=
d to explicitly opt into that possibility by redeclaring the readonly pr=
operties. From the point of view of the parent class, nothing will chang=
e, except false expectations=E2=80=94and it is a good thing that false e=
xpectations are eliminated.
>> * Relatively of Options 3 and 4, Option 2 leaves the language in a mo=
re simple and regular state.

That's a valid point, actually.  The implicit "private(set)" is already =
untrue because of readonly-specific workarounds to enable redeclaration.=
  Switching it to implicit "protected(set)" would remove that special ca=
se, and still allow an explicit private(set) if desired (which would the=
n imply final).

Since no one else has weighed in, we'll go with that route: readonly on =
its own changes to implicit protected(set), remove any special casing, a=
nd then readonly and aviz should be safely compatible.  I'll update the =
RFC and Ilija will confirm that there's no implementation gotchas we're =
not aware of yet.

> Hello everyone,
> I've been seeing readonly bashed/blamed/being roadblock, etc, etc as i=
n=20
> the implementation ended up being sloppy and blocking other things or=20
> making things hard...=20
> While I know BC is king and stuff, why not just say "yes, this was=20
> designed badly and we will redo it" and just do it? While there's not=20
> yet an absolute boatload of that code out there when it would be=20
> absolutely massive BC break? Don't repeat the mistakes of the old days=20
> :D

Well, readonly has been out for 3 years.  There is an absolute boatload =
of code out there that we do not want to break. :-)

> Cause the impression I'm getting any significant RFC now has to work=20
> around the readonly's sloppy implementation and there's a bigger and=20
> bigger section on that with each next RFC when there's more and more=20
> advanced features for the OOP part of things.

It's not a sloppy implementation per se.  (I can't actually speak to the=
 implementation myself.)  It's the design of an implicit private(set) th=
at works differently from any other private variable.  The issue with "t=
hou shalt not touch it outside of the constructor" isn't a language bug,=
 it's a static-analyzer bug that those projects refuse to fix.  Not some=
thing we can really do much about here.  Uninitialized wasn't introduced=
 by readonly but by property types in 7.4; readonly just inherited it.  =
For hooks, the issue is that readonly needs a value to check to see if i=
t's uninitialized, and with hooks, you don't always have that.

I think at this point, the change discussed above (making it implicit pr=
otected(set)) is the best we could do.  In an ideal world, we would have=
 never added readonly in the first place and just added aviz back in 8.1=
, which would cover nearly all the same use cases with fewer edge cases =
and oddities.  Sadly, the world is not ideal.

--Larry Garfield