Agreed, where did I say otherwise?Maugrim_The_Reaper wrote: The point I would make (in PHP at least) is that using statics for performance gains is premature optimisation.
What I meant was that statics are a language tool, like defining a member as const, but more limiting. To go making your functions static just for performance would be crazy and is not at all what I was suggesting. However to say their indicative of bad design is equally as rediculous.
Actually their not global methods...they don't clutter the namespace...not that you didn't know this already...just clearing that up for other readersMaugrim_The_Reaper wrote: In the scope of Design, all that achieves is numerous global methods and little measurable performance gain
Don't need to. I'm pretty sure it's just the 'this' pointer which get's dereferenced...minimal hit on performance I agree 110% but to use a method when a static would work better or visa-versa for the sake of "looser" coupling or performance gains...well IMHO thats just silly...Maugrim_The_Reaper wrote: (has anyone using this actually measured the gain???).
I disagree (this is subjective however) I personally always favour solid design. Using statics when they make sense - slight performance boost is simply a positive side effect but *not* the driving force behind choosing to use them or not.Maugrim_The_Reaper wrote: There are times to compromise between good design and optimisation but I doubt statics is one of them
Statics on the contrary when used properly are even less tightly coupled than members dude. The idea behind a static is not to start working on GLOBALS because you don't have access to members...but instead keep functionality specific to that function only (keeping in a class namespace for organization purposes) using the arguments as your only input. In this regard a static is actually loosely coupled with any object.Maugrim_The_Reaper wrote: I'd accept a tiny performance hit for looser coupling - most of us have accepted such hits in the past when PHP5 first came out
That's because MFC is a foundation or framework...Zend is more a class library than a framework. It's a collection of classes which try to optionally work togather explicitly controlled by a client developer, rather then being implicitly designed to depend on each other - which a RAD framework like MFC does.Maugrim_The_Reaper wrote: In MFC those concerns are moot - MFC is a class library and most libraries are tightly coupled
The reasons for this are two fold:
=======================
1. PHP developers don't like dependancies because of the runtime overhead/environment.
2. GUI in Windows or desktop development traditionally require an API. PHP when it's used in a web environment has the luxury (or curse) of having it's GUI almost entirely separated (HTML). GUI widgets or components, whatever...naturally lend themselves to an object hierarchy whereas generic classes like what Zend offers don't so they avoid inheritence and side with composition instead. Looser coupling but only because they can or have too. I see little wrong with design here, but rather just doing whats best given your working environment.
Again I fail to see how statics damage or destroy a loose coupled design??? Unless you use statics with globals, etc...in which case it's not the design that's flawed its your programming techniques....Maugrim_The_Reaper wrote: it's extremely loosely coupled and allowing too many statics only damages that aspect.
Huh??? What do you mean? If you call the static internally yes the class becomes dependant on knowing it's own name...but PHP does offer the __CLASS__ constant??? You might also be able to use the get_class()Maugrim_The_Reaper wrote: Note that using a static in a class, means that class must be aware of the static's class name.
Likewise if you call the static externally (like MFC to remove a file) yes you have to use the class name::method but again in PHP you could use get_class() on an object couldn't you? Slightly more flexible code (incase your class names change) but less clear as well. Besides I'd rather use the actual class name. I would favour easier to read code than less fragile in this case.
You lost me thereMaugrim_The_Reaper wrote: If we spend so much time discussing alternatives to direct instantiation and Singleton static calls like Class_Name::getInstance() peppering our class constructors (tight coupling) - like Registry, Service Locator and Factories, then we should apply the same measures where possible to another reason for class coupling - static methods.
Cheers