Zend weakness
Moderator: General Moderators
Zend/Pear class naming allows for you to know exactly where the file is by looking at the class name... seems to me that if you were to change that it would make it more difficult for the client coder. If YOU change directory structure, clients will have to change their includes, class names etc. regardless of your naming scheme. I really don't see your point at allHockey wrote:The reason is to prevent client users from *ever* having to modify *their* code because of something *you've* done. API changes, include directory changes, etc...they are all changes which must then be reflected in your clients codebase, which is a bad thing.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Dude...I like you, so I won't go ballistic...we have lots in common in that were both nuttsThe Ninja Space Goat wrote:Zend/Pear class naming allows for you to know exactly where the file is by looking at the class name... seems to me that if you were to change that it would make it more difficult for the client coder. If YOU change directory structure, clients will have to change their includes, class names etc. regardless of your naming scheme. I really don't see your point at allHockey wrote:The reason is to prevent client users from *ever* having to modify *their* code because of something *you've* done. API changes, include directory changes, etc...they are all changes which must then be reflected in your clients codebase, which is a bad thing.
You basically repeated verbatim what I was saying and what the problem is and yet still can't see the problem, which in itself is a problem...do you follow me now?
I can't be bothered to explain it any further here, I'm not even sure I'm on the right track, but I think I am...and I'll continue to research and likely write a blog about it...
When I am complete, you will do me a favour and read it...and then give me your thoughts? Capeesh?
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Thats fine, don't include it, follow the path of others...for my own definition...I do consider scalability somewhat analogous to project longevity.arborint wrote:Quite honestly "project longevity/source tree expansion" is in no description of scalability I have ever heard, and I don't intend to start including it. I am still unclear how is this naming style has much effect on the project in the ways you have mentioned. If you use another scheme you will have to edit the files that contain the paths when you move files. If you also rename the class you will need to edit the files for that. Using PEAR style names you always do both -- which might reduce errors because there is no "maybe" involved. And given modern editors these type of changes are trivial.Hockey wrote:Perhaps my definition of scalability is different than yours. Mine is more loosely defined, in the sense that project longevity/source tree expansion falls under the same hood as scalability. My definition is more broad than just simply pertaining to scaling to more user/hardware.
You are being shockingly practicalAmbush Commander wrote:Ermm... forgive me if someone mentioned this already, but why not create a compat/ directory that emulates old classnames/classpaths for compatibiliy?
1) If a project doesn't scale...it's lifetime is limited...
2) If a project has difficulties growing...it *probably* won't scale well either
The former is an absolute truth, the latter is somewhat subjective, as a crappy design can still scale if you throw enough hardware behind it. But by that logic, we might as well start advocating that anything can fly if you put enough thrust behind it.
So what you are saying then is you see no problems with Zend's current directory structure, despite not really having any counter argument, except to say...???
I need you to answer the above quite clearly...I guess I'm kinda dumb and unpractical that way
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Those have nothing to do with any definition of scalablity that I know. I don't believe either is a truism.Hockey wrote:1) If a project doesn't scale...it's lifetime is limited...
2) If a project has difficulties growing...it *probably* won't scale well either
I very clearly and repeatedly stated the problem -- there are somewhere between zero to twice as many things to rename when you move a file compared to other schemes. I also stated the main benefit to PEAR style naming. I believe that those who choose PEAR style naming believe the benefits outweigh that negative.Hockey wrote:So what you are saying then is you see no problems with Zend's current directory structure, despite not really having any counter argument, except to say...???
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
LOL...You seriously need to read up on your design patterns, OOD principles, etcarborint wrote:Those have nothing to do with any definition of scalablity that I know. I don't believe either is a truism.Hockey wrote:1) If a project doesn't scale...it's lifetime is limited...
2) If a project has difficulties growing...it *probably* won't scale well either
I very clearly and repeatedly stated the problem -- there are somewhere between zero to twice as many things to rename when you move a file compared to other schemes. I also stated the main benefit to PEAR style naming. I believe that those who choose PEAR style naming believe the benefits outweigh that negative.Hockey wrote:So what you are saying then is you see no problems with Zend's current directory structure, despite not really having any counter argument, except to say...???
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Of course, but I'm tired of arguing when it's so obvious he's either arguing for the sake of arguing or doesn't understand the subject at hand well enough to bother arguing.patrikG wrote:Do you have anything to substantiate your view and refute aborint's?Hockey wrote:LOL...You seriously need to read up on your design patterns, OOD principles, etc
It breaks a number of 'good' software design rules/policies, some unoffical and others well documented like the ones which he constantly advocates in such an authoritive manner.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
So other than accusing me of "seriously need to read up on your design patterns, OOD principles, etc" and "arguing for the sake of arguing" or that I don't "understand the subject at hand well enough", you have no more specific response than "It breaks a number of 'good' software design rules/policies, some unoffical and others well documented". I fully admit that my knowledge of design patterns and OOD is far from complete. However I believe I generally understand the pros and cons of PEAR style naming, as well as the reasons for the Zend Frameworks using it.
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
uhh...fine...arborint wrote:So other than accusing me of "seriously need to read up on your design patterns, OOD principles, etc" and "arguing for the sake of arguing" or that I don't "understand the subject at hand well enough", you have no more specific response than "It breaks a number of 'good' software design rules/policies, some unoffical and others well documented". I fully admit that my knowledge of design patterns and OOD is far from complete. However I believe I generally understand the pros and cons of PEAR style naming, as well as the reasons for the Zend Frameworks using it.
List the pros and cons of each and i'll see if were on the same page, then I will hilight/elaborate where my arguments lie...until now you've refused to except my arguments as valid and instead refused to find any faults with the Zend/PEAR naming scheme. IMHO you've done little but question me in such a way that it appears you were hoping to catch me making an error and make it publically known, which admittedly I am now doing the same thing.
I have about a 5 very good reasons (all backed by statements from those professionals you always reference) why it's bad, but it takes time to write it out and include you counter aguments and counter argue those...I'd much rather blog about it as it's content worth posting on my web site IMHO.
so please, list your known pros and cons, instead of looking for fault or arguments in what I say, and perhaps we can both come to a conclusion or agreement.
Maybe you interpreted what I said wrong, because I wasn't in any way reiterating what you said... so here is what I said explained...Hockey wrote:You basically repeated verbatim what I was saying and what the problem is and yet still can't see the problem, which in itself is a problem...do you follow me now?
I'm saying this meaning that it is convenient... for the client coder.The Ninja Space Goat wrote:Zend/Pear class naming allows for you to know exactly where the file is by looking at the class name
This is where I think you may have misinterpreted me... I meant... if you change the way classes are named to NOT reflect their location in the directory structure, how will they know where the files are? Can you think of even ONE more logical way to map classes to their locations? Keeping in mind both ease for humans and computers of course...The Ninja Space Goat wrote:seems to me that if you were to change that it would make it more difficult for the client coder.
You argued that a client coder should NEVER have to change their code to reflect changes to the library code... OK, well if you change directory structure, won't they have to change their includes to reflect your change in location? You're not making any sense to me.The Ninja Space Goat wrote:If YOU change directory structure, clients will have to change their includes, class names etc. regardless of your naming scheme. I really don't see your point at all
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Perhaps our definition of framework differs thenI'm saying this meaning that it is convenient... for the client coder.
As anyone will tell you who has worked with various frameworks, which includes me as I've worked with atleast a dozen over the last tens years. A framework is intended to assist the client developer not the core developers developing the framework. Some get it right and others get it wrong. Zend is in the latter boat.
First mistake they make, which never occured to me until I sat down and thought about it. What advatnage does a client have in knowing "where" a file or class module/etc is located?
Zip!!! Ideally a client when working with a class/component/framework/library/etc should never need any knowledge of "where or why" just deal with "what or which" solves their problem. A well documented framework will have examples of "what" classes solve which problems...and that is the extent of knowledge a client ever needs. Once they begin tinkering in the implementation aspect of a framework, they have transitioned from client to core developer. The core developers primary job is making the framework as easy to use as possible (well thought out API) and also hiding any unessential details from the client. By virtue of the fact the Zend class names related directly to a directory structure, that golden rule is broken. As the client is now has direct knowledge (by just being a client) of how the file system is organized. It's not nessecarily a bad thing, but it's frowned upon. Ideally the client doesn't need to gain *any* insight into the framework internals.
As a client developer, again, you should ever need to know...but...you will need to know if you wish to include them in your applications, so atleast you need a location of the file. Most frameworks, MFC/OWL/wxWindows/etc have the include path inside the documentation of that particular class/component, etc...This is where I think you may have misinterpreted me... I meant... if you change the way classes are named to NOT reflect their location in the directory structure, how will they know where the files are? Can you think of even ONE more logical way to map classes to their locations? Keeping in mind both ease for humans and computers of course...
In fact i'm pretty sure phpDocumentor even does this...
Yes, but I said this didn't I? Changing or replacing an include path however, is not the same as changing a class name. There is a massive difference from a solid design perspective.You argued that a client coder should NEVER have to change their code to reflect changes to the library code... OK, well if you change directory structure, won't they have to change their includes to reflect your change in location? You're not making any sense to me.
Cheers
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I have stated the extra renaming problem with PEAR style naming several times, and I believe you agreed with me at one point. I also mentioned "the benefits of generating file paths from class names (and vice versa) that is the basis of that scheme" as a pro. I believe I also mentioned the consistency of always having to change both the path and the class name as a possible pro. So far I believe you have mentioned: brittle, a hassle, and scalability as cons and no pros that I recall.Hockey wrote:so please, list your known pros and cons, instead of looking for fault or arguments in what I say, and perhaps we can both come to a conclusion or agreement.
I believe this an important subject and one that many PHP programmers will find useful. Many will need to deal with it once the Zend Framework is released because it will be widely used due to Zend's backing. This naming style is also a basis of PEAR's packaging technology. I do not think the naming scheme will cause the brittleness, undo hassles or scalability problems that you mention.
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Ok first off I have used PEAR but I am not overly familiar with it. Secondly it has more of a library feel than a framework. Not to mention is has a collection of rather reduandant classes, like Auth for example...I assume this is because unlike Zend they accept new packages more easily than Zend. Zend appears to have peer review before making it an official package - which is a good thing and partially what attracted me to Zend.arborint wrote:I have stated the extra renaming problem with PEAR style naming several times, and I believe you agreed with me at one point. I also mentioned "the benefits of generating file paths from class names (and vice versa) that is the basis of that scheme" as a pro. I believe I also mentioned the consistency of always having to change both the path and the class name as a possible pro. So far I believe you have mentioned: brittle, a hassle, and scalability as cons and no pros that I recall.Hockey wrote:so please, list your known pros and cons, instead of looking for fault or arguments in what I say, and perhaps we can both come to a conclusion or agreement.
I believe this an important subject and one that many PHP programmers will find useful. Many will need to deal with it once the Zend Framework is released because it will be widely used due to Zend's backing. This naming style is also a basis of PEAR's packaging technology. I do not think the naming scheme will cause the brittleness, undo hassles or scalability problems that you mention.
Secondly, it's possible none of these problems I have with Zend will cause any real problems, however I don't need MVC for any real applications and I will likely get by just fine. Of course the larger the applications the more complicated things become and the more and more MVC starts making sense. It'll depend on the growth of Zend I suppose. These problems will however affect my own framework, which even in it's early planning stage would likely encounter problems. So I assure you these are potential real problems.
Problems:
1) Good design is often always related to loose coupling, you know this, so the relationship of class name/directory structure should scream something at you. Rigity! You cannot change one without feeling the effects in the other.
2) A framework, has no need to expose the directory to a client via the class name. This is a feature only useful to core developers, which goes against good framework design. The minute you start making things easier for core developer you will likely start negatively effecting client developers.
3) The number one rule of OOD is likely the OCP: An object/component should be open to extension but closed for modification. This means, you should never need to modify your class API *ever*
When you design/release a class/component you sign a perpetual contract which stipulates that any changes to the public interface of a class or component will like cause software fragility. Fragility is the inability for software to be easily changed without feeling any side effects. You change the public interface of a class and your client developers now feel the effects.
A class name, whether you agree or not, is part of that interface contract. They are mutually bonded, one cannot exist without the other. You change one, the API feels it you change the API the class name will feel it. this particularly true in statically invoked functions.
Code: Select all
Some_Class::getInstance4) Assuming you accept these arguments, now lets' consider the fact that organization works on many levels in software development and patterns, OOD principles, best practices apply to all levels of software development, not just source level, but directory structure, project management and so on.
What makes practical sense on the source code level does not nessecarily transcend nicely into the directory structure...
For instance, consider the fact that many Linux libraries often have directories called "Libs" which contain sub-libraries or whatever. At the file scope, this makes sense, but mapping a class name to "Zend_Security_Libs_Crypt_Md5" does not make sense, is convoluted and again is introducing file structure (which is only pertinent at the file scope) to the source code level. Libs would be completely useless inside a class name other than letting the developers know where is sits inside a directory tree. This include information is best left out of class names (as directory structure is volatile) whereas class names should be immutable.
4 factors which are indications of code rott/bad design:
1) Fragility
2) Rigidity
3) Immobility
4) Viscosity
Although Zend naming scheme seems fine, it actually coincides with at least 3 of the 4 factors of software rott.
You cannot change a class name because it causes Fragility and because of that fact your application is now in a state of Rigidity. You cannot reuse code internally because if the file changes location, the class name must change which means inside your framework you must also now find those class names and replace them with their new location. Not to mention the extra work your client developers might have to do. Because of this, your framework suffers from Immobility as well...Thats 3 rules broken which are crucial to solid design.
Now the inspired reader might ask: "How is it a class name is part of the component contract, but the inlude() file is not?"
Good question and thanks for paying attention
Simple, they are two very different levels of organization:
1) Source code level
2) Source tree level
The include path's are not part of the component contract because unlike a class contract which is rigid, a file structure/source tree is volatile and subject to change. The component contract simple doesn't apply to the source tree level (which is where the include falls under).
A component should be capable of being stored wherever it makes sense, not bound tightly to a specified file because a framework says so. It's very common in C++ for instance for many classes to share the same source file. Not saying it's a good idea, although sometimes logically (at the source tree level) it does make sense. Typically a components helper classes are either nested directly in the class or stored laterally - I've seen and used both methods in many projects.
There should be no hardened relationship between source code and source tree...if there is should be coincidence not concrete. Loose coupling people, remember that.
In regards to any arguments about IDE's being able to quickly replace class references. Sure, but not everyone has a IDE that powerful. Secondly class names constructed on the fly using some string magic and then executed at runtime:
Code: Select all
$cls_prefix = 'someclass_prefix';
// ... some more code
$cls_postfix = 'someclass_postfix';
$class_name = $cls_prefix.'_'.$cls_postfix;
$object = new $class_name();
$object->someAPI();many people use this dynamic runtime class instantiation technique, perhaps over used by over zealous newbies, but the fact is...it's used and a framework should take that into account as it's trying to appeal to the widest audience possible.
include() on the other hand is most typically hardcoded. In compiled langauges like C++ in fact it's impossible to not hardcode the include path, whereas runtime class instantiation is quite possible. Despite this fact, even if include was dynamically constrcuted on the fly...it's a lot easier to find and trace than a runtime object instantiation.
The basis of my arguments is this:
A source tree is volatile, if you argue otherwise, I would strongly suggest you work on larger projects. A class name or it's public interface are concrete and should NEVER change, it's what gives OOP such an advantage over procedural as this policy is easier to suggest or influence onto developers. The capability of having a component which "drops" right into your application and you never have to worry about it again is what makes classes/components so powerful and appealing...
COM...the most widely used and likely popular component based system out there actually forces these rules and for a reason. Its a proven best practice.
I am *not* advocating Zend sucks, in fact I use it myself and plan on continuing it's usage in future projects and the points I mentioned above don't bother me personallyh enough NOT to use it, but I will not implement that naming scheme in my own framework is all that I was saying.
Through these arguments, I can probably drum up about a dozen more, but I think you should all be getting the point by now.
Cheers
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
How? The directory naming is itself based on the class name and general grouping - the naming is not dependent on the filesystem, it's the opposite.The core developers primary job is making the framework as easy to use as possible (well thought out API) and also hiding any unessential details from the client. By virtue of the fact the Zend class names related directly to a directory structure, that golden rule is broken.
Interclass loose coupling is a pro. The filesystem dependency on class names is a simple convention which does not constitute the form of coupling a client need worry about (least not to the extent you're suggesting) in PHP. I don't care where a class is located, so long as my code will always be capable of including it and it has a decent name. A lot of thought goes into class naming. And generally its spot on. The PEAR naming convention has been in place for years and has had no serious issues I know of.1) Good design is often always related to loose coupling, you know this, so the relationship of class name/directory structure should scream something at you. Rigity! You cannot change one without feeling the effects in the other.
No, but a classname should make immediate sense. When I see Zend_Http_Response, I immediately know what I'm dealing with. It's blatantly obvious from the descriptive naming convention. That it is reflected in the directory structure is an added bonus (and since when is it that modifying open source code is supposed to be made difficult?). A client has other ways of finding file locations for alternatives.2) A framework, has no need to expose the directory to a client via the class name.
This is the preferred ideal. Every ideal ever created always has exceptions. "Ever" encompasses a very long time and even with refactoring eventually any project will change its API at some point. Over the past few iterations of the ZF, such changes have been quite easy to adapt to and the effort to make it that easy comes during preview releases of all things. Can you actually name any project that has *never* changed a single class interface? I can't. Not saying they don't exist, but I would suspect they're far being a majority...3) The number one rule of OOD is likely the OCP: An object/component should be open to extension but closed for modification. This means, you should never need to modify your class API *ever*
I'd venture the ZF follows an established standard which has been acceptable to professional PHP developers for a very long and extended time across countless use cases. Class name changes are easily amended - every decent editor (let alone IDE) has a search and replace function. Combine that with updated unit tests and you're golden. Exceptions will then be quickly identified for further minor edits.
A last observation. Can you please make your future posts more like this one?