On Thu, 30 May 2024, Alexandru Pătrănescu wrote:
> On Wed, May 29, 2024 at 10:18 PM Larry Garfield <[email protected]>
> 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