Re: Proposal: use SomeClass::staticMethod

From: Date: Wed, 15 Aug 2012 19:52:10 +0000
Subject: Re: Proposal: use SomeClass::staticMethod
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-62200@lists.php.net to get a copy of this message
Giedrius Dubinskas wrote:
On Wed, Aug 15, 2012 at 6:54 PM, Lester Caine <lester@lsces.co.uk> wrote:
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?
Sorry, I'm not sure I follow. Would it be possible provide some examples of what you mean? My proposal does not change anything to existing code. It only adds to readability where it is most desired. I picked PHPUnit example just to show that there is a desire for it in real world applications and in that particular case looks like inheritance was used (IMHO incorrectly) to reduce noise of prefixing class to each static method call for assertion and mocking matcher. With my proposal it would be posible to reduce this noise even more. I am not saying that this feature would be used everywhere nor that it should. But it would add a lot where it is already most desired. And FWIW for PHPUnit it would work out of the box. The static methods are already there. One would just need to `use` them :-)
Overriding just one version of 'staticMethod' with a shorthand is going to make working out WHICH version is being called all the more difficult to understand as one has to find a use clause to which it relates somewhere further up the code chain? Simply to identify the relevant block of code that is being actioned. In real applications (PHPUnit are not a real application only test case actions) there will be several occurrences of say 'getDisplayUrlFromHash' for the base class and for each specialised descendant class, so that referring to one via shorthand does not work practically. There may be special cases where it could be used, but that is just the sort of 'creep' that we need to avoid? At some point using the shorthand has to be replaced with the proper version simply because a different version of the code is needed. The main problem I have here is that having reworked the code to remove all the strict warnings/errors, I'm still not sure that the resulting code IS following the right rules, so it may well be that there is another way of building descendent static code that works more like you expect it to? -- 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

« previous php.internals (#62200) next »