On Sat, Jun 8, 2024, at 3:49 AM, Arvids Godjuks wrote:
> 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?
That is essentially what we've ended up on. For *services*, aviz is probably
not super useful; for that matter readonly is only marginally useful in
services, but a lot of people (myself included) use it as a matter of course
anyway. The only change we're discussing there is that "public readonly" or
"protected readonly" will now be implicitly "protected(set)" instead of
implicitly "private(set)". If you're already using "private readonly", then
that will actually get a bit stricter as it removes the loophole that exists
only for readonly. So this is a very small, focused change.
Aviz is much more useful for data classes: value objects, DTOs, domain models,
ORM models, and so on. For that, readonly serves one narrow use case and does
it well, but falls apart and often gets in the way for anything even slightly
more complex/interesting. For that, aviz offers vastly more flexibility and
robustness in about the same amount of syntax.
--Larry Garfield
