> So we feel the best way forward is to make the following changes: > > * private(set) implicitly means "final". (You can declare it explicitly if you want, but it isn't necessary.) > * Make readonly incompatible with aviz again.
I'd make readonly incompatible with aviz. Readonly props have its "peculiarities" that are being (found and) changed on each version. If you don't want to change your value ever, use readonly. If you want more flexibility, use aviz. Making workarounds on the aviz RFC so it can be compatible with readonly is not worth it, IMO. Best regards, Erick Em sex., 31 de mai. de 2024 às 20:53, Claude Pache <claude.pa...@gmail.com> escreveu: > > > Le 31 mai 2024 à 18:08, Larry Garfield <la...@garfieldtech.com> a écrit : > > So we feel the best way forward is to make the following changes: > > * private(set) implicitly means "final". (You can declare it explicitly > if you want, but it isn't necessary.) > * Make readonly incompatible with aviz again. > > Thoughts? > > > > After reflection, I don’t think that we need to make readonly incompatible > with aviz, even with the current semantics of readonly (at least logically; > no idea about implementationally): > > * legacy-readonly properties could keep their own peculiar > `private-overridable(set)` if they want; > * aviz-readonly properties have, by definition, one of `public(set)`, > `protected(set)` or `private(set)` marker; those will work regularly, > including the implicit `final` attached to `private(set)`; > * a non-aviz readonly property could not be redeclared in a subclass as > aviz-readonly, and vice versa. > > —Claude >
