On Fri, May 31, 2024 at 10:30 AM Claude Pache <claude.pa...@gmail.com> wrote:
> > > Le 30 mai 2024 à 17:07, Derick Rethans <der...@php.net> 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 > Yes, thank you; that's a good point. Seems like another issue with readonly, but then again, the private(set) part of readonly is not really explicitly designed, I guess. > > 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). > Yes, it seems like a good enough option, and use "final public private(set)" to ensure only the current class will be able to set the value. If we all agree, I think this should be documented in the RFC. There is another small problem, I think, with "final" modifier not being allowed for constructor-promoted properties. And maybe we can have this fixed in the current RFC if this ends up being "the correct" way to define public-read private-write properties. Regards, Alex
