Page 1 of 4

Zend weakness

Posted: Tue Sep 26, 2006 8:55 pm
by alex.barylski
What scares me about *every* framework I have ever worked with and over the last decade I've worked with a lot is API stability, which is worse than a buggy code base.

While sifting through Zend for ideas for my own framework I stumbled across an interesting weakness in their over all design.

The class names map to the location where the class resides, which is handy when wanting to edit the file and makes the classes purpose very obvious - in this case the tight 1:1 relationship or binding is of good practical use.

For instance:

Code: Select all

Zend_Region_Object
Would map to the file system as so:

Code: Select all

Zend/Region/Object
I can appreciate this tight coupling...however, in such a new-ish framework it makes the API dangerously unstable or de-modularizes (makes it monolithic) the file system layout, one or the other.

If I start using Zend_Config today and later on they decide to throw Zend_Config into a sub directory (Zend_Misc_Config) to better modularize their source tree, I would either have to use Zend::loadClass and load the class manually (no biggie) but the namespace doesn't share the same 1:1 relationship which makes it useful in the first place...

So apparently that naming scheme is flawed :P

At first I liked it, but now after coming to this conclusion...I'm second guessing it as a feasable scheme.

It's nice, makes your class files easy to find and makes the namespace clear as day...but kind of hardens the source tree modularity don't you think?

Just thought I'd share and poll for opinions :)

Cheers :)

Posted: Tue Sep 26, 2006 9:07 pm
by neophyte
I think that naming/directory tie is becoming a common feature of Frameworks because of the way __autoload() works. PEAR documentation calls for using the same naming conventions. I don't know if CakePHP uses the same tight naming for classes but I know that their directory tree is rigid. App classes and files all exist in a separate folder "apps".

Posted: Tue Sep 26, 2006 9:17 pm
by alex.barylski
neophyte wrote:I think that naming/directory tie is becoming a common feature of Frameworks because of the way __autoload() works. PEAR documentation calls for using the same naming conventions. I don't know if CakePHP uses the same tight naming for classes but I know that their directory tree is rigid. App classes and files all exist in a separate folder "apps".
Yea, personally I'm using the same convention in my own framework...but when that occured to me...it kinda kicked me off my rocker for a sec :P

Most source trees over time change and are refactored accordingly...so...for obvious reasons I'm taking a second peak.

p.s-I just peaked at Cake...scaffolding eh? I finally get it...the point behind it...makes sense, although I personally am not too kean on having that as an intergral part of a framework...

Best suited in a third party RAD tool, but I guess you use what you have available :P

Posted: Tue Sep 26, 2006 9:21 pm
by neophyte
Yuppers, and God forbid you find yourself renaming a directory -- the cascading name changes 8O

Posted: Tue Sep 26, 2006 9:27 pm
by alex.barylski
neophyte wrote:Yuppers, and God forbid you find yourself renaming a directory -- the cascading name changes 8O
At the file system level isn't my concern...as any files which depended on the previous location could likely be found easily (includes are usually hardcoded).

It's the dynamic class invocation I'd be worried about...

Switching Zend_This to Zend_This_That when the name may be constructed on the fly inside your code somewhere, which is virtually impossibl to find using search tools, but requires either knowing the codebase well or sifting through all the files, etc and finding any instances which might do that.

Posted: Tue Sep 26, 2006 9:32 pm
by neophyte
TRUE -- Those can be a real PITA.

Posted: Wed Sep 27, 2006 5:23 am
by Maugrim_The_Reaper
This is always a danger - but mind the ZF is still on its preview path. Once they hit 1.0 such changes should be reasonably rare.

Posted: Wed Sep 27, 2006 7:00 am
by MrPotatoes
i think you over analyze everything in your framework

Posted: Wed Sep 27, 2006 10:40 am
by Maugrim_The_Reaper
If API changes in your framework are a worry, I would check into Refactoring to limit its impact - am I stating the obvious here? :)

Posted: Wed Sep 27, 2006 12:17 pm
by Christopher
Are you saying that PEAR style naming "hardens" the naming scheme because you have to change both the inlcude path and the class name when you move a class? Are you referring to having to do two search-and-replaces rather than one? Then you worry about class names that are constructed on the fly, but before that you seem to say that the PEAR naming scheme helps with that problem by making the location of the files obvious? So are you advocating that PEAR naming is better?

Posted: Wed Sep 27, 2006 1:47 pm
by MrPotatoes
oh man you lost me on that one lmao

Posted: Wed Sep 27, 2006 2:38 pm
by alex.barylski
Maugrim_The_Reaper wrote:This is always a danger - but mind the ZF is still on its preview path. Once they hit 1.0 such changes should be reasonably rare.
I have to disagree...I've worked with and on many frameworks which change file structure through their lifetime. So unless PHP is magical or the Zend developers can see into the future...it's not the best approach to solving the problem.
Mr Potatoes wrote:i think you over analyze everything in your framework
I'm anal about everything I do...why do it period if you don't do your best or obsess about every detail? I get that characteristic from my old man who is an air craft mechanic. Personally I'd prefer people who were anal about every detail fixing the air plabnes on fly rather than those who let details pass them by, either by complacency or ignorance. Would you? :P
Maugrim_The_Reaper wrote:If API changes in your framework are a worry, I would check into Refactoring to limit its impact - am I stating the obvious here?
Ummm...yea just a bit...but by refactoring...you are making more work for yourself and a framework is suppose to do just the opposite...but I too am stating the obvious, so I guess were in the same boat... :P :lol:
Arborint wrote:Are you saying that PEAR style naming "hardens
I don't remember saying anything about PEAR, but perhaps I did :?
Arborint wrote:Are you referring to having to do two search-and-replaces rather than one?
Yup
So are you advocating that PEAR naming is better
Again I don't remember mentioning PEAR at all :(

I'm not advocating anything, other than I'm sure there is a better method or approach which makes more sense...

What am I saying is that file structure will change undoughtedly (100% gaurantee for any project that lives past version 1.0). What I am saying is that once your file directory changes and you update the class names (if you chose to do so) would be a hassle, not for framework developers so much but for clients using your framework. So really both parties are effected.

I thought I made my concerns pretty clear? So what part of my point didn't you get?

Are you implying that Zend naming scheme is the best way?

Personally after some thought, I would tend to disagree.
1) Classes will change as well as their directory locations...maybe more in the beginning...but change is perpetual. Everytime you refactor the directory tree, you need to refactor your code as well as your clients...
2) IMHO using __autoload() as a debug function informing you of when and where your includes choked and allowing a dynamic file structure *might*be a better way of doing things.

I am not advocating Zend is better than PEAR or visa versa...I will say I personally prefer Zend over PEAR...PEAR is more of a library whereas I see Zend as a framework.

Cheers :)

Posted: Wed Sep 27, 2006 2:43 pm
by Jenk
I have, admiteddly, skimmed most of this thread - but two things strike me here:

1. Lack of namespaces are a contributor to this problem.

2. If you are finding yourself moving classes around in your framework, that classifies as a design flaw with your framework, in my opinion :)

Posted: Wed Sep 27, 2006 2:58 pm
by alex.barylski
Jenk wrote:I have, admiteddly, skimmed most of this thread - but two things strike me here:

1. Lack of namespaces are a contributor to this problem.

2. If you are finding yourself moving classes around in your framework, that classifies as a design flaw with your framework, in my opinion :)
1. I'll think about that one and get back to you..

2. Care to justify your answer with pragmatic reasoning, or are you just following the trend? :P

Posted: Wed Sep 27, 2006 3:19 pm
by Luke
As far as class-naming, I think Zend is on par... (and they use the same naming scheme as PEAR I think... which is where arborint got PEAR from). I don't really see changing the directory/name of a class as that much of a necessity. I think that, in general, classes should not need to be moved around that often. Changing code within classes is a different story though... one which will have no effect on this issue at all.