Re: [RFC] [DISCUSSION] Immutable/final/readonly properties

> > I totally agree with this: there must be a way to work around the keyword - > either via reflection or another means. Via Reflection, it could be a new method ->setWritable(true) (next to > ->setAccessible(true)). > I'm OK to support working around the keyword via reflection. Since my implementation uses a property flag to determine if a property is writable, and the flag is flipped after writing, the ->setWritable(true) wouldn't work. But I can imagine adding a ->setUninitialized() method, or adding a third parameter to ->setValue() which would affect whether the property flag should be first reset or not. Adding a separate ->setValue() method for this purpose is also possible, but I couldn't find a good name for that yet. What do you think? > Another way, which is my current preference, would be to have visibility be > taken into consideration when using the keyword: > To be honest, I don't agree with this idea. It is rather a simpler property accessor variant with which one can define separate - but predefined - visibility rules for reading and writing. Furthermore, I think it's worth to protect people from their own mistakes. I know for sure that at least I'd need those safeguards. :) But if we are talking about unintended changes coming from outside scopes, and if we only consider "legal" use-cases, private and protected properties are already pretty much safe. However, if we also consider possible changes coming from an inside scope, and other, "illegal" use-cases, we currently don't have any protection. And not even property accessors or your idea could help here. Given, immutability became mainstream via PSR-7 at least, I think it would be beneficial to add first-class support for this principle. I remember that one of the criticisms against the implementation of PSR-7 was that immutability is not even possible to achieve in PHP (apart from the fact that PSR-7 uses a mutable resource for storing the body). Now, we could solve the first problem, but that requires us to stay with the proposed implementation of the RFC. Regards, Máté