Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123559
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> <CAL0xaBFSAp0ewzRyDmWBLwkbAus13LF7mKqW59QUd0x2c9jtkQ@mail.gmail.com>
 <0b6d7308-3c32-477c-8bf2-e8e0880cbb05@app.fastmail.com>
In-Reply-To: <0b6d7308-3c32-477c-8bf2-e8e0880cbb05@app.fastmail.com>
Date: Sat, 8 Jun 2024 11:49:33 +0300
Message-ID: <CAL0xaBECrK5F2bYskSGGoAo8OodV8JqOwfFgNOptkRzPF9pumQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000df88ae061a5d00a5"
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000df88ae061a5d00a5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 7 Jun 2024 at 17:30, Larry Garfield <larry@garfieldtech.com> wrote:

> 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>
> wrote:
> > *snip*
> > 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
>
> Well, readonly has been out for 3 years.  There is an absolute boatload o=
f
> code out there that we do not want to break. :-)
>
> > 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.
>
> 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) that
> works differently from any other private variable.  The issue with "thou
> 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 something we
> can really do much about here.  Uninitialized wasn't introduced by readon=
ly
> 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 it's uninitialize=
d,
> and with hooks, you don't always have that.
>
> I think at this point, the change discussed above (making it implicit
> protected(set)) is the best we could do.  In an ideal world, we would hav=
e
> 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
>

It does depend on what the fix is - if we are talking removing readonly
keyword - that's a yikes and if we go that route, it needs to have an
official rector migration thing and it better be officially endorsed and
provided :)
If we are talking about tweaking how readonly works in some cases - while
not great, I hold the opinion that it's better to fix it now than 20 years
down the line.

I do have to say that I do not see a "=3D=3D" between aviz and readonly. Wh=
ile
I can see how you can implement readonly with aviz, the boilerplate seems
not worth it, especially for bigger classes/structures where you just
designate the whole class with one "readonly class MyClass { ... }". And
constructor promotion with "private readonly Class $class" with DI is
basically all my services now - it's convenient and short and I really do
not need any more than that from the readonly :) Maybe simplifying readonly
is the answer and use aviz for more complicated cases?
--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--000000000000df88ae061a5d00a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, 7 Jun 2024 at 17:30, Larry Garfie=
ld &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>=
&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">On Wed, Jun 5, 2024, at 7:55 PM, Arvids Godjuks wrot=
e:<br>
&gt; On Wed, 5 Jun 2024 at 19:59, Claude Pache &lt;<a href=3D"mailto:claude=
.pache@gmail.com" target=3D"_blank">claude.pache@gmail.com</a>&gt; wrote:<b=
r>
&gt; *snip*<br>&gt; Hello everyone,<br>
&gt; I&#39;ve been seeing readonly bashed/blamed/being roadblock, etc, etc =
as in <br>
&gt; the implementation ended up being sloppy and blocking other things or =
<br>
&gt; making things hard... <br>
&gt; While I know BC is king and stuff, why not just say &quot;yes, this wa=
s <br>
&gt; designed badly and we will redo it&quot; and just do it? While there&#=
39;s not <br>
&gt; yet an absolute boatload of that code out there when it would be <br>
&gt; absolutely massive BC break? Don&#39;t repeat the mistakes of the old =
days <br>
&gt; :D<br>
<br>
Well, readonly has been out for 3 years.=C2=A0 There is an absolute boatloa=
d of code out there that we do not want to break. :-)<br>
<br>
&gt; Cause the impression I&#39;m getting any significant RFC now has to wo=
rk <br>
&gt; around the readonly&#39;s sloppy implementation and there&#39;s a bigg=
er and <br>
&gt; bigger section on that with each next RFC when there&#39;s more and mo=
re <br>
&gt; advanced features for the OOP part of things.<br>
<br>
It&#39;s not a sloppy implementation per se.=C2=A0 (I can&#39;t actually sp=
eak to the implementation myself.)=C2=A0 It&#39;s the design of an implicit=
 private(set) that works differently from any other private variable.=C2=A0=
 The issue with &quot;thou shalt not touch it outside of the constructor&qu=
ot; isn&#39;t a language bug, it&#39;s a static-analyzer bug that those pro=
jects refuse to fix.=C2=A0 Not something we can really do much about here.=
=C2=A0 Uninitialized wasn&#39;t introduced by readonly but by property type=
s in 7.4; readonly just inherited it.=C2=A0 For hooks, the issue is that re=
adonly needs a value to check to see if it&#39;s uninitialized, and with ho=
oks, you don&#39;t always have that.<br>
<br>
I think at this point, the change discussed above (making it implicit prote=
cted(set)) is the best we could do.=C2=A0 In an ideal world, we would have =
never added readonly in the first place and just added aviz back in 8.1, wh=
ich would cover nearly all the same use cases with fewer edge cases and odd=
ities.=C2=A0 Sadly, the world is not ideal.<br>
<br>
--Larry Garfield<br>
</blockquote></div><br clear=3D"all"><div>It does depend on what the fix is=
 - if we are talking removing readonly keyword - that&#39;s a yikes and if =
we go that route, it needs to have an official rector migration thing and i=
t better be officially endorsed and provided :)</div><div>If we are talking=
 about tweaking how readonly works in some cases - while not great, I hold =
the opinion that it&#39;s better to fix it now than 20 years down the line.=
</div><div><br></div><div>I do have to say that I do not see a=C2=A0&quot;=
=3D=3D&quot; between aviz and readonly. While I can see how you can impleme=
nt readonly with aviz, the boilerplate seems not worth it, especially for b=
igger classes/structures where you just designate the whole class with one =
&quot;readonly class MyClass { ... }&quot;. And constructor promotion with =
&quot;private readonly Class $class&quot; with DI is basically all my servi=
ces now - it&#39;s convenient and short and I really do not need any more t=
han that from the readonly :) Maybe simplifying readonly is the answer and =
use aviz for more complicated cases?</div><span class=3D"gmail_signature_pr=
efix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"=
ltr"><div><br></div>Arv=C4=ABds Godjuks<div>+371 26 851 664</div><div><a hr=
ef=3D"mailto:arvids.godjuks@gmail.com" target=3D"_blank">arvids.godjuks@gma=
il.com</a></div><div>Telegram: @psihius=C2=A0<a href=3D"https://t.me/psihiu=
s" target=3D"_blank">https://t.me/psihius</a></div></div></div></div>

--000000000000df88ae061a5d00a5--