> 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 <[email protected]>
escreveu:
>
>
> Le 31 mai 2024 à 18:08, Larry Garfield <[email protected]> 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
>