Re: [RFC] Asymmetric visibility

On Thu, Aug 11, 2022, at 8:48 AM, Nicolas Grekas wrote: >> Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: >> Asymmetric Visibility. >> >> https://wiki.php.net/rfc/asymmetric-visibility >> >> Details are in the RFC, but it's largely a copy of Swift's support for the >> same. >> > > Thank you Larry and Ilija for this RFC. > > After reading it, I'm wondering about inheritance rules. What would be the > rules when redeclaring an existing asymmetric property in a child class? > The RFC should mention them I believe. Yeah, Ilija is working on that still, I believe. I believe the plan is, as with properties now, to allow widening access but not narrowing. static properties will also be supported, but that implementation is WIP. > But I'm also wondering about the use case where asymmetry would be useful > in practice now that we have readonly? > I voted against readonly at the time because it didn't address cloning, and > also because it deprives end-users vs code authors IMHO (alike "final"). I > would have very much prefered asymmetric visibility back then. But now that > we are here, what are the use cases? If it's cloning only, then I would > very much prefer finding a way to fix it rather than providing two subtly > different ways to achieve the same thing. > > Eg can't we allow __clone methods to bypass the readonly restrictions? The > engine already handles "guards" when using magic property accessors. Can't > we use something similar for clone? > > And if yes, what would remain of the motivations for the asymmetric RFC? > > Cheers, > Nicolas There's a couple of use cases I see off hand: 1) Cloneability, as you've noted. 2) Fixing inheritance with readonly. Right now, readonly is only settable from private scope, not protected. So child classes are SOL. 3) A property that is rebuild based on other properties. Eg, public private(set) $fullName, which is updated internally whenever $o->setFirstName() or $o->setLastName() are called. (Or with accessor hooks in the future, which is on the roadmap.) There's likely others, too. I would also have rather had AV in the first place rather than readonly, as readonly is now getting in the way. :-( But there are things readonly cannot reasonably do, and that's made worse by bad assumptions that static analysis tools have made about its usage. We're working on a response to some other points made, but want to get on the same page with some more details first. Stay tuned for a follow up. --Larry Garfield