Re: [RFC] Asymmetric Visibility, v2

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* >> 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: “Proposal feels unfinished since it >> can'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 moving towards a messy hodgepodge of features >> that don't work well together.” >> >> 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—and it is a good thing >> that false expectations are eliminated. >> * Relatively of Options 3 and 4, Option 2 leaves the language in a more 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 case, and still allow an explicit private(set) if desired (which would then 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, and 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 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