> Most of the use cases you talk about are easily emulated from within > the class. If you're calling unset($foo->bar) from outside of the > class, I would argue the code is bad and needs to be rethought to begin > with.
That may be so - we can judge the code PHP enables all we want, but the fact remains that PHP does allow this kind of thing and it can and will happen in the future. As the language evolves we should not be adding *more* inconsistency - like `unset()` now only working on some things and not others, and which ones work and which ones throw fatal errors being opaque to the consumer. That's leaving a footgun lying around and a violation of encapsulation. > From within the class, the RFC linked to several examples, the first > few of which involved caching of derived properties. > Problem solved. Of course, one can work around almost anything. I'm hoping to envision a solution in which workarounds are not necessary by following established PHP idioms. In the workarounds in the RFC, we either 1) double the number of properties in the class by including separate private cache variables, which is annoying to maintain and extend, and becomes a code convention instead of natural PHP. (Ironically, we `unset()` those private cache variables!!) Or we 2) introduce a more complex situation with private cache arrays and magic constants. If we're talking about bad code, magic constants are certainly up there. IMHO it's much more natural to simply unset the property from inside the class, like PHP has always allowed us to do and is what one of the very workarounds in the RFC does. The fact that the workaround in the RFC does it demonstrates how useful it is!
