Giedrius Dubinskas wrote:
On Wed, Aug 15, 2012 at 6:54 PM, Lester Caine <les...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
