Posted: Thu Sep 28, 2006 10:08 pm
Nice game of chess then. But do you honestly believe that the Zend-framework will run into trouble because a class-name is too long? I mean: really?
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
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.
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.
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?
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...???
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...???
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
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
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.
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
Perhaps our definition of framework differs thenI'm saying this meaning that it is convenient... for the client coder.
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...
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.
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.
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.
Code: Select all
Some_Class::getInstanceCode: 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();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*