> Le 30 mai 2024 à 17:07, Derick Rethans <[email protected]> a écrit :
>
>>
>> Now, if I define the property as public private(set) with similar
>> intentions, to make sure that there is no way for external scope or
>> extending classes scope to write to the property, while allowing
>> reading from external scope (or extending classes scope).
>>
>> But the problem is that an extending class can define the property as
>> public protected(set), and that will easily allow the property that I
>> wanted to make sure it is private for writing to be changed by an
>> extending class to be protected.
>
> public private(set) properties aren't really private, so you don't get
> the shadowing, but you do have a point wrt to the expectation that an
> inherited class can't easily override the private(set) part (with
> protected(set) or public(set)).
Note that the issue already exists today with readonly properties: those are basically private(set);
but if you redeclare a non-private readonly property in a subclass, you can in fact initialise it
from the subclass bypassing the initial private(set) restriction of the superclass: https://3v4l.org/9AV4r
If you want a property not to be overridable, end of story, you can mark it as final
(the final marker for properties was added as part of the hooks RFC, but it works also with
non-hooked properties).
—Claude