Richard Quadling wrote: > (Not E_STRICT) If error_reporting does not include E_STRICT, then > unset()'ting properties defined in interfaces is allowed and operates > exactly as it does on normal variables and for properties defined in > classes. Whilst this may break the contract, this is what currently > happens and for the sake of BC (until a better solution is found), we > leave things alone. Personally, I think the potential new feature of > properties defined in interfaces should not be allowed to be unset. > But I'm looking at what I want with this and I hope that the following > text allows it. > > (E_STRICT) If error_reporting does include E_STRICT, then unset()'ting > properties defined in interfaces is not allowed and triggers an > E_STRICT error.
We don't need this distinction: If you unset a property and access it afterwards you get an E_NOTICE so it can already be detected. And introducing different semantics depending on E_*-modes opens up another can of worms a la ini settings: Writing an application compatible with all different modes becomes a PITA. I agree with Stas here: Theoretical OO purism (I yet have to be shown code misbehaving with the current implementation) should not lead to artificial restrictions and/or code changes with BC breaks. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
