Todd Ruth wrote:
Could there be a compromise that would allow us evildoers to continue in our evil ways without identifying and changing every use? Perhaps "implements allowStaticCallsFromIncompatibleContexts" or somesuch? I can imagine replacing every "class ..." with "class ... implements ...", but identifying and changing every place we use an incompatible context will be very, very unpleasant. We can figure out the places that are hit most frequently using the logs, but that isn't necessarily a complete list.
It's all this 'implements' and the like which is complicating things along with 'the proper way of doing things'
The exercise that I am STILL working through is one where an objects function used to be used statically as well as via $this ... if $this existed use it otherwise generate a static result. As far as I am concerned still there was nothing wrong, but I've gone through the exercise and written a HECK of a lot more code switching a single function into three functions! A static call, a $this call and often a further static function that has the shared code. I forget now why the static call could not be used directly ... OH matched parameters across all classes ... the base static has a subset of the class ones.
The main point here is that there was nothing functionally wrong with the PHP5.2 code, it had been doing it's job perfectly, leave E_STRICT off and the code continues to work! I don't like this comparison with E_DEPRECATED, that is a different concept in my mind ... E_STRICT is purely style police imposing other peoples style choices, so the current debate IS appropriate, and it's nice to hear a few more voices against some of this.
I can see that the resulting code changes improve the code, but I know I am still missing a lot of the 'style changes' that I SHOULD be using simply because of only hitting the E_STRICT warnings. It's a decent 'style' scanner that is needed rather than these odd warnings in the core code :( To some extent phpdocumenter helps here as the generated documents do flag up some of what as been missed but certainly not all.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
