Posted: Wed Sep 27, 2006 3:25 pm
it's just organizational. where a class is doesn't really matter. it's the functionality that's important
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
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?
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
Since you asked..Hockey wrote:2. Care to justify your answer with pragmatic reasoning, or are you just following the trend?
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.
?>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'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
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.
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.
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...
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...
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?
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?