On Fri, 7 Jun 2024 at 17:30, Larry Garfield <la...@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.pa...@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 of
> 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 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 it's uninitialized,
> 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 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
>
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 "==" between aviz and readonly. While
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?
--
Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius
