Zeev Suraski wrote: ...
> > > My recommendation: > - Add a new flag to methods (at the implementation level) that will > allow to flag them as 'strict' > - In case such a strict method is improperly overridden - error out > (E_ERROR) > - In case a non-strict method is improperly overridden - emit E_STRICT > - Consider adding userland ability to set entire classes or methods as > strict > > Most people who use 'strict OO' will have E_STRICT enabled and have > their code E_STRICT clean, so providing userland support for tagging > classes/methods as strict is probably not really necessary. one thing occur to me (from a enduser's POV): E_STRICT is often used to denote usage that is depreciated and/or 'evil' with the implication (when it's not explicitly mentioned) that in future one will no longer be able to rely on the said usage. this makes, by implication, anything that produces an E_STRICT is 'second class' which I believe is not the implication that should be made here. E_STRICT has seemingly been abused regarding it's meaning and it seems to me that there is a need to differentiate between strictness and depreciation (E_DEPRECIATED? E_EVIL?). I personally don't want to write/use code that is depreciated [if I can help it] but mostly I don't give 2 hoots about strictness (for instance, I'm quite disciplined enough to write matching method signatures in relevant subclasses when that is needed; without php always forcing it upon me) kind regards, Jochem PS - very nice to see someone come with up with a definite suggestion that does take into account the voice of the [legion of?] php-nobodies who have concerns/issues regarding the 'strictness' stuff that's been creeping in lately. > > Zeev > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
