On Thu, 30 May 2024, Alexandru Pătrănescu wrote: > On Wed, May 29, 2024 at 10:18 PM Larry Garfield <la...@garfieldtech.com> > wrote: > > > As promised, Ilija and I offer this revised version of asymmetric > > visibility. > > > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > > > > Hey Larry, Ilija, > > I have one concern so far, and it's related to the inheritance section. > > If in a class I define the property as private, > I know that there is no way for external scope or extending classes scope > to read or write to the property. > (of course, ignoring reading/writing using reflection or re-binded closures) > > If an extending class defines the property with a wider visibility, > protected or public, it will shadow the initial one and not change its > visibility.
private and protected differ here already, even without async visibility: https://3v4l.org/8Ynog A protected property does not create a new bag to store data in, which does happen for a private property. > 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)). Hopefully Ilija or Larry can explain :-) cheers, Derick
