Zend weakness
Moderator: General Moderators
- MrPotatoes
- Forum Regular
- Posts: 617
- Joined: Wed May 24, 2006 6:42 am
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Zend uses PEAR naming conventions.Hockey wrote:I don't remember saying anything about PEAR, but perhaps I did![]()
So are you saying that it is a design weakness of PEAR naming and therefore the Zend Framework? Or do you just personally consider having to do two search and replaces when you move a class to be a hassle?Hockey wrote: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?
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
It's just organizational??? 
Riiiiight...
Arborint...I'm saying it's a weakness as I stated in subject heading...
May I ask, what source tree's have you examined over the years and seen a monolithic directory structure???
Zend could add new classes and attempt to organize them better...but the original classes are perpetually stored, forzen in time, because if they change, the namespace changes...which breaks client code as well as their own possibly.
Also, assume their framework grows into a monster with 1,000's of files and 100's of directories...and they do decide to better modularize their source tree...
You might end up with class names so long they run you off the page (exaggerated).
I'd much prefer 2 or 3 at MOST. Again the example is exaggerated, but often theories need exaggeration for people to see their practical use.
If you need or want long class names as illustrated above...you either need glasses...a programming tutor or a hockey helmut and full contact padding, cause I think you'd be a danger to your self (not directed at anyone in particular just saying in general)
Cheers
Riiiiight...
Arborint...I'm saying it's a weakness as I stated in subject heading...
May I ask, what source tree's have you examined over the years and seen a monolithic directory structure???
Zend could add new classes and attempt to organize them better...but the original classes are perpetually stored, forzen in time, because if they change, the namespace changes...which breaks client code as well as their own possibly.
Also, assume their framework grows into a monster with 1,000's of files and 100's of directories...and they do decide to better modularize their source tree...
You might end up with class names so long they run you off the page (exaggerated).
Personally, as descriptive as it is...ia way to long for me...2 maybe three and at absolute MOST 4 sections per namespace...Zend_Application_SubSystem_Core_Module_Config_Status_Helper_Abstract
I'd much prefer 2 or 3 at MOST. Again the example is exaggerated, but often theories need exaggeration for people to see their practical use.
If you need or want long class names as illustrated above...you either need glasses...a programming tutor or a hockey helmut and full contact padding, cause I think you'd be a danger to your self (not directed at anyone in particular just saying in general)
Cheers
Since you asked..Hockey wrote:2. Care to justify your answer with pragmatic reasoning, or are you just following the trend?
1. Lack of namespaces; notice the difference:
Java:
Code: Select all
import java.io.*
class MyClass
{
BufferedReader buff;
public static void main (String[] args)
{
buff = new BufferedReader(System.in);
// etc..
}
}Code: Select all
<?php
include 'Zend.php';
Zend::loadClass('Zend_Controller_Front');
$front = Zend_Contoller_Front::getInstance();
//etc.
?>In php, pseudo namespacing doesn't allow this flexibility. The class name is Zend_Controller_Front, not Front. We use pseudo namespace of directory structure with Zend/Controller/Front.php. So if you move it to a different directory, you'll need to change the class name to match it's new directory.
2. If you are moving classes about after completing your framework, yes, it is a design flaw. If it were designed appropriately, then it would be Zend_Misc_Config to start with, and not need changing. However, in all honesty - what difference does it really make that it is in Zend_Config or Zend_Misc_Config.
Note that you'll also need to update any extensions to reflect the addition of Misc.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
So you consider having to do two renames rather than one a weakness in that naming scheme, and you appear to be saying that you consider that a flaw in the Zend Framework (and PEAR by extension). Ok. I take it that you consider the extra renaming to be a sufficient weakenss that it outweighs the benefits of generating file paths from class names (and vice versa) that is the basis of that scheme?
Also, now you are saying that the problem is that the names are too long. That's new and different than you OP. Do you consider the long names a weakness or just a hassle? Are long names a greater problem for you than the extra renaming? Or less of a problem?
Also, now you are saying that the problem is that the names are too long. That's new and different than you OP. Do you consider the long names a weakness or just a hassle? Are long names a greater problem for you than the extra renaming? Or less of a problem?
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
I wasn't refering to the namespace issue, but thanks anywaysSince you asked..
Just as source code is volatile the same applies to a properly organized source tree, unless your of the type who throws everything into the root directory, such as Zend has currently done, and only focuses on keeping code modular via files, etc...f you are moving classes about after completing your framework, yes, it is a design flaw. If it were designed appropriately, then it would be Zend_Misc_Config to start with, and not need changing. However, in all honesty - what difference does it really make that it is in Zend_Config or Zend_Misc_Config
I can tell you from experience, that a monolithic file structure quickly becomes an annoyance and slowly becomes an impedance. The ability to quickly locate files or determine it's purpose when browsing a large source tree is imperative to RAD.
In all fareness (I do repsect & appreciate the Zend developers I think what they've done is good, just could be better IMHO) the guys/girls over at Zend likely don't anticipate their framework growing *much* larger than what it is right now...
But if it does, you can count on them wanting to reorganize their structure to better reflect module organization...it's just another layer of organization...one level from source code...if you can't see that and how a properly organized source tree is a good thing, then thats your bad.
Cheers
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
I'm saying it's a weakness in design, not a flaw as it still works it's just not *as* scalable as a naming scheme which doesn't have the 1:1 coupling that my own framework follows.arborint wrote:I take it that you consider the extra renaming to be a sufficient weakenss that it outweighs the benefits of generating file paths from class names (and vice versa) that is the basis of that scheme?
No, actually I'm saying the names (assuming they did as I have done) *could* potentially blow up to a length in which they become an impedance rather than a importance.arborint wrote:Also, now you are saying that the problem is that the names are too long
A weakness in design? Not all as the code would still be workable and scablable...but having to rememberDo you consider the long names a weakness or just a hassle
Exaggerated as I did the first time, but clearly you don't see what I'm saying so I exaggerated againThis_Is_A_Class_That_Does_Just_A_Simple_Thing_And_Has_A_Very_Long_Name_to_Boot_No_Pun_Intended
A name of that length, is annoying and would likely lead to many difficulties in getting your code to parse after changing or using namespaces like that. It's pretty obvious to me, that mistyping a single character would choke your script. So yes, weakness, no...annoying yes...negative attribute, yes, as it slow down my development.
The real point is, I prefer clean, clear class names (Zend_Config, Zend_DB, etc) which IMHO are just as (maybe more) obvious as Zend_SomeDir_SomeDir2_Config which 2 months later could possibly be renamed to Zend_SomeDir3_Config.
Zend will not change their directory structure, because it would be a PITA for client developers to have to adjust the code which uses them. Incase you didn't know, when you right code and follow all those guidelines and best practices you like so much advocating, you supposed to consider your classes/interfaces public functions as perpetual contracts which should *not* change.
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 arguments go like this (if I understand you correctly):
Here are my arguments:I would rather have a class name which reflected the exact location inside the library, then a shortened (albeit just as clear and obvious to the end user) classname. Because, even if the class gets relocated to reflect it's purpose conceptually in the source tree and thus requiring a change to their class namespace in client code, I personally prefer having precise knowledge of where the class is physically located, even though that information is useless to the end user (client programmer) who doesn't care about how or why the framework is setup but rather just wants it to work.
1. Like I said in the last sentance: The end user of a framework, ideally doesn't need to know about how or where files are located. They just want it to work and look good. Short class names, such as Zend_Config are best, as Zend_ is strictly an adhoc hack to fix the lack of namespaces in PHP (this makes sense). The latter serves the purpose of explaining what the object is. Admittedly, directory structure can tell you alot about what an object/class is and that perhaps verbose names such as (Zend_Specialized_Config_Interface) are more clear, that just doubly backs up my argument in that, it proves directory structure can be helpful in organizing your code and yet another level outside of just the source code itself.
Hmmmmmmmm... I'm done debating...continue using that naming scheme if you so desire...
Cheers
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
I just want consistency. Zend's naming scheme is consistent. Hence I am happy with it. Maybe if you proposed an actual alternative you could persuade the Zenders to change things before 1.0. PHP5 is imperfect but one has to live within its limits... Neither is the file system heavyhanded - the class depth is around 2-3 which makes things a lot easier in terms of location and organisation.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
I agree...consistency and good docs is why I switched to Zend...and I still think it's a great framework, but future scalability is hindered, by the fact the classnames share such a tight coupling with directory names...Maugrim_The_Reaper wrote:I just want consistency. Zend's naming scheme is consistent. Hence I am happy with it. Maybe if you proposed an actual alternative you could persuade the Zenders to change things before 1.0. PHP5 is imperfect but one has to live within its limits... Neither is the file system heavyhanded - the class depth is around 2-3 which makes things a lot easier in terms of location and organisation.
Thats ultimately the only argument I have in this regard, but it causes several sub-arguments(if you will) to sprout up...
But as I said, I'm done debating this issue...
If your interested in sharing ideas or swaping thoughts PM and I'd be glad to continue with you...publically...I'm done
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I can see no reason why classnames mirroring directory paths will effect future scalablity in the least. I can't even see how it is connected to scalablity at all. It would be the same files any way they were organized.Hockey wrote:but future scalability is hindered, by the fact the classnames share such a tight coupling with directory names...
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
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.arborint wrote:I can see no reason why classnames mirroring directory paths will effect future scalablity in the least. I can't even see how it is connected to scalablity at all. It would be the same files any way they were organized.Hockey wrote:but future scalability is hindered, by the fact the classnames share such a tight coupling with directory names...
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
No one mentioned that yet (as far as I know)Ambush Commander wrote:Ermm... forgive me if someone mentioned this already, but why not create a compat/ directory that emulates old classnames/classpaths for compatibiliy?
From what I can tell, your solution works well, if they used loadClass()
I'll be honest I didn't even consider your approach...but good on you...it's why I post here...in hopes someone will see where I'm coming from and offer a reasonable response + argument, not just an argument.
I need to think about it for a second more before I agree 100% but I think you may have just called "check mate"
I'll get back to you...
Cheers
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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?
(#10850)