Page 2 of 2

Posted: Thu Nov 09, 2006 8:35 pm
by alex.barylski
Maugrim_The_Reaper wrote: The point I would make (in PHP at least) is that using statics for performance gains is premature optimisation.
Agreed, where did I say otherwise? :?

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.
Maugrim_The_Reaper wrote: In the scope of Design, all that achieves is numerous global methods and little measurable performance gain
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 readers ;)
Maugrim_The_Reaper wrote: (has anyone using this actually measured the 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... :P
Maugrim_The_Reaper wrote: There are times to compromise between good design and optimisation but I doubt statics is one of them
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: 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
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: In MFC those concerns are moot - MFC is a class library and most libraries are tightly coupled
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.

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.
Maugrim_The_Reaper wrote: it's extremely loosely coupled and allowing too many statics only damages that aspect.
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: Note that using a static in a class, means that class must be aware of the static's class name.
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()

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. :)
Maugrim_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.
You lost me there :P

Cheers :)

Posted: Fri Nov 10, 2006 3:17 am
by Maugrim_The_Reaper
I think you lost me after the first sentence ;). Just kidding...

Back in my first post I talked about the scope of a static. If you take a static method (take the ZF) called Zend::register() it has a few features. Since the class is loaded, and the static public, it's globally accessible. This has nothing to so with GLOBALS as in global variables, or anything (not sure you meant that). Namespacing is not an issue. Maybe you were looking in from another perspective?

Considering the usefulness of Zend::register() and Zend::registry(), it's reasonable to assume it will be commonly used whenever a Registry is required (there being no alternate ZF Registry implementation until 0.20). Of course using it anywhere has one impact - you need to know the class is called "Zend". This adds a dependency to other classes, and adds coupling. If I take that class, and move it to a new project I will need to edit the class, remove the dependency, and adapt a replacement Registry.

Now, if someone were to go insane and use statics simply because the method does not access the parent class's properties, or its supposedly faster, or whatever, then there could conceivably be dozens of statics floating around. They *may* in many cases be public, if so they are all globally accessible, and therefore will only end up (if used) binding classes closer together and making it even more difficult to extract a class for reuse.

That was the main point I was raising. From that perspective, statics will raise a few code smells in time. The smelly nature of the Zend statics in the ZF is already resulting in refactoring across multiple components.

I'll bypass the rest of your points - we don't actually disagree on much. ;) Your comments on MFC are on the money, and describe most libraries (unfortunately) in PHP even. Unlike the MFC, most of the PHP libs using this approach are IMO, so specific and interdependent to be perfectly useless outside the developers' intended usage - regardless of the broad number of separable tasks they may perform.

That's probably why I like the Zend Framework so much. I can mix and match from components, include optional libraries, extend and modify to my hearts content, use alternate classes, the works.