Giedrius Dubinskas wrote:
My main aim with this suggestion is readability. I'd like to remove unnecessary noise in code where it doesn't add any value to the reader. Code is easy to type (especially with good autocompletion) but it is read more often then typed and I think that is important. Or is it just me?
Depends who is doing the reading? Since a static method should be provided with all the data it needs to produce a result, does it actually matter what it is called and how it is called? Of cause it does when one is trying to find the right descendent method of the class?
I've already been told that the code I'm working on upgrading is archaic but it works fine. The bulk of the recent work has been pulling $this out of functions and creating a static section for many that handles the results of building a hash from the object, or supplying a ready built one. I'm told that it's bad practice to include the static functions within the class? But they are an integral part of processing the object, or are overridden by functions in the descendant objects. So 'staticMethod' has to be the right one for the object created, and SomeClass:: depends on the object being created. So how does the proposal cope with that type of structure?
-- 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
