On Mon, Aug 5, 2024, at 8:49 AM, Theodore Brown wrote: > On Fri, July 26, 2024 at 12:25 Larry Garfield wrote: > >> Voting for Asymmetric Visibility is now open. >> >> https://wiki.php.net/rfc/asymmetric-visibility-v2 > > Hi Larry and Ilija, > > Thank you for all your work on this RFC! > > One part that doesn't make sense to me is this sentence near the end in > the "Readonly is incompatible with inheritance" section: > >> With asymmetric visibility, the `readonly` usage here can be replaced with >> `protected protected(set)` or `readonly protected protected(set)`, avoiding >> the need to double-declare properties. > > `protected protected(set)` just removes readonly, and is the same as > `protected`, right? So couldn't such a change be done now without > asymmetric visibility? > > And the change to `protected protected(set) readonly` as shown in the > example also seems unnecessary, since earlier in the RFC it says that > readonly will be changed to imply `protected(set)` rather than > `private(set)`. So it seems that no change is needed to the abstract > class here - the properties can remain `protected readonly`, and the > implementation can be simplified since readonly properties will now > imply `protected(set)`. > > Or have I misunderstood something here?
I believe in this case you're correct. That example was written early on, before we decided to expand readonly to protected(set) by default. I didn't realize that needed to be updated as well. Yes, in this case, the widening of readonly would also resolve that issue. `protected protected(set)` would now be redundant, but not hurt anything, whereas `protected private(set)` would have an effect. `public public(set) readonly` would also be legal (though I don't personally know why you'd do that, there's no inherent reason to make it illegal). --Larry Garfield
