Re: [Vote] Asymmetric visibility v2

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