IMO good as-is: can be relaxed later (8.3 or later), if anybody believes it's a show-stopper.
Readonly classes don't really need to be lazy. Marco Pivetta https://twitter.com/Ocramius https://ocramius.github.io/ On Fri, 2 Sept 2022 at 19:31, Nicolas Grekas <nicolas.grekas+...@gmail.com> wrote: > Hello everybody, hi Mate > > I played with readonly classes recently, to add support for them to > lazy-loading proxy generation and I struggled upon what I see as serious > issues. > > As noted in the RFC, and because the readonly flag must be set on child > classes, those cannot: > > 1. Declare a new non-readonly property; > 2. Have static properties; > 3. Have dynamic properties. > > I figured out 1. and 2. not by reading the RFC but because I needed those > capabilities in the generated inheritance proxies. > > 1. is the most serious one: being able to declare a non-readonly property > is the only way to implement a cloneable proxy (to be allowed to do > $this->realInstance = clone $this->realInstance; in __clone()). I think > there are two ways to solve the use case I have: A. fix the > non-cloneability of readonly props or B. allow child classes to add > non-readonly properties. Because to me this is a serious restriction, A or > B should ideally be in 8.2. I think A is a must-have so that might be the > thing to do. But I'm also wondering about B: the RFC doesn't contain any > rationale about why this restriction exists (it says "Similarly how > overriding of readonly properties works", but the similarity is quite weak, > readonly props don't apply to other properties of child classes.) If there > is no compelling reason to have this limitation, it should be removed IMHO. > Basically, this would mean that child classes of readonly classes wouldn't > have to be readonly themselves (but the existing properties on the parent > would have to be of course.) > > For 2.: static properties are useful e.g. to cache some shared state (info > extracted from reflection in my case) and I really don't see why readonly > classes should forbid static properties. Readonly is only useful for > instances, because it gives them immutability, but what's the link with > static properties? Note that this is less important than the previous point > as it's always possible to store shared global state in another class. But > still, this feels arbitrary to me. > > For 3. I just noted the limitation to be exhaustive, but I'm really fine if > dynamic properties remain forbidden on child classes. It might be seen as > inconsistent with other classes, but dynamic properties don't have any > purpose anyway since there is always an alternative to them. > > I understand there are good intentions behind these limitations (making PHP > a stricter language). But here, I feel like this is detrimental to the > language, by making it a minefield of kinda arbitrary dos and don'ts. At > least that's what I feel here. > > Does that make sense to you? Should we remove the limitations I mention? > > Nicolas > PS: About allowing readonly props to be reinitialized during cloning, I > tried https://github.com/php/php-src/pull/9403 but I failed as I can't > make > it work. I'd appreciate any help on the topic. I'd even be happy to close > if someone else would like to work on the topic. Could that be you? >
