Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123527
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <10AAAA51-9538-4F97-83D1-91F154C745F7@gmail.com>
Date: Wed, 5 Jun 2024 22:55:21 +0300
Message-ID: <CAL0xaBFSAp0ewzRyDmWBLwkbAus13LF7mKqW59QUd0x2c9jtkQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
To: Claude Pache <claude.pache@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000805261061a29f432"
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000805261061a29f432
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 5 Jun 2024 at 19:59, Claude Pache <claude.pache@gmail.com> wrote:

> *snip*
> Hi Larry and Ilija,
>
> Thanks for your work. Here is my opinion:
>
> First, I do think that `readonly` should integrate with aviz, unless that
> implies truly controversial changes on `readonly`. As Theodore Brown
> commented in the previous version of the RFC: =E2=80=9CProposal feels unf=
inished
> since it can't be used in conjunction with readonly properties/classes. I=
n
> my opinion the issues with this need to be resolved first, to avoid the
> language moving towards a messy hodgepodge of features that don't work we=
ll
> together.=E2=80=9D
>
> 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
> readonly properties can *already* be written to from a child class as of
> today: it suffices that the child class in question redeclare those
> properties: https://3v4l.org/9AV4r. From the point of view of the child
> class, the only thing that will change, is that it will no longer be
> required to explicitly opt into that possibility by redeclaring the
> readonly properties. From the point of view of the parent class, nothing
> will change, except false expectations=E2=80=94and it is a good thing tha=
t false
> expectations are eliminated.
> * Relatively of Options 3 and 4, Option 2 leaves the language in a more
> simple and regular state.
>
> =E2=80=94Claude
>
>
>
Hello everyone,
I've been seeing readonly bashed/blamed/being roadblock, etc, etc as in the
implementation ended up being sloppy and blocking other things or making
things hard...
While I know BC is king and stuff, why not just say "yes, this was designed
badly and we will redo it" and just do it? While there's not yet an
absolute boatload of that code out there when it would be absolutely
massive BC break? Don't repeat the mistakes of the old days :D

Cause the impression I'm getting any significant RFC now has to work around
the readonly's sloppy implementation and there's a bigger and bigger
section on that with each next RFC when there's more and more advanced
features for the OOP part of things.

--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--000000000000805261061a29f432
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, 5 Jun 2024 at 19:59, Claude P=
ache &lt;<a href=3D"mailto:claude.pache@gmail.com">claude.pache@gmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv><div>*snip*</div><div>Hi Larry and Ilija,</div><div><br></div><div>Thank=
s for your work. Here is my opinion:</div><div><br></div><div>First, I do t=
hink that `readonly` should integrate with aviz, unless that implies truly =
controversial changes on `readonly`. As Theodore Brown commented in the pre=
vious version of the RFC: =E2=80=9CProposal feels unfinished since it can&#=
39;t be used in conjunction with readonly properties/classes. In my opinion=
 the issues with this need to be resolved first, to avoid the language movi=
ng towards a messy hodgepodge of features that don&#39;t work well together=
.=E2=80=9D</div><div><br></div><div>Second, I think that making `readonly` =
implicitly `protected(set)` by default (Option 2) is the way to go:</div><d=
iv>* At first glance it is an expectation change. But, in reality, all read=
only properties can *already* be written to from a child class as of today:=
 it suffices that the child class in question redeclare those properties:=
=C2=A0<a href=3D"https://3v4l.org/9AV4r" target=3D"_blank">https://3v4l.org=
/9AV4r</a>. From the point of view of the child class, the only thing that =
will change, is that it will no longer be required to explicitly opt into t=
hat possibility by redeclaring the readonly properties. From the point of v=
iew of the parent class, nothing will change, except false expectations=E2=
=80=94and it is a good thing that false expectations are eliminated.</div><=
div>* Relatively of Options 3 and 4, Option 2 leaves the language in a more=
 simple and regular state.</div><div><br></div><div>=E2=80=94Claude</div><d=
iv><br></div><div><br></div></div></blockquote></div><div><br></div>Hello e=
veryone,<div>I&#39;ve been seeing readonly bashed/blamed/being roadblock, e=
tc, etc as in the implementation ended up being sloppy and blocking other t=
hings or making things hard...=C2=A0</div><div>While I know BC is king and =
stuff, why not just say &quot;yes, this was designed badly and we will redo=
 it&quot; and just do it? While there&#39;s not yet an absolute boatload of=
 that code out there when it would be absolutely massive BC break? Don&#39;=
t repeat the mistakes of the old days :D</div><div><br></div><div>Cause the=
 impression I&#39;m getting any significant RFC now has to work around the =
readonly&#39;s sloppy implementation and there&#39;s a bigger and bigger se=
ction on that with each next RFC when there&#39;s more and more advanced fe=
atures for the OOP part of things.</div><div><div><br></div><span class=3D"=
gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signa=
ture"><div dir=3D"ltr"><div><br></div>Arv=C4=ABds Godjuks<div>+371 26 851 6=
64</div><div><a href=3D"mailto:arvids.godjuks@gmail.com" target=3D"_blank">=
arvids.godjuks@gmail.com</a></div><div>Telegram: @psihius=C2=A0<a href=3D"h=
ttps://t.me/psihius" target=3D"_blank">https://t.me/psihius</a></div></div>=
</div></div></div>

--000000000000805261061a29f432--