> 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 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
