Page 2 of 4

Posted: Wed Sep 27, 2006 3:25 pm
by MrPotatoes
it's just organizational. where a class is doesn't really matter. it's the functionality that's important

Posted: Wed Sep 27, 2006 5:29 pm
by Christopher
Hockey wrote:I don't remember saying anything about PEAR, but perhaps I did :?
Zend uses PEAR naming conventions.
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?
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?

Posted: Wed Sep 27, 2006 6:30 pm
by alex.barylski
It's just organizational??? :P

Riiiiight... :lol:

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. :P

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).
Zend_Application_SubSystem_Core_Module_Config_Status_Helper_Abstract
Personally, as descriptive as it is...ia way to long for me...2 maybe three and at absolute MOST 4 sections per namespace...

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) :P

Cheers :)

Posted: Wed Sep 27, 2006 7:01 pm
by Jenk
Hockey wrote:2. Care to justify your answer with pragmatic reasoning, or are you just following the trend? :P
Since you asked..

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..
    }
}
PHP with Zend:

Code: Select all

<?php

include 'Zend.php';

Zend::loadClass('Zend_Controller_Front');

$front = Zend_Contoller_Front::getInstance();

//etc.

?>
Notice how in Java, because of the namespace java.io, you don't need to call BufferedReader by java.io.BufferedReader everytime, so if you change it's namespace, you only need to update your import's.

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.

Posted: Wed Sep 27, 2006 7:10 pm
by Christopher
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?

Posted: Wed Sep 27, 2006 7:22 pm
by alex.barylski
Since you asked..
I wasn't refering to the namespace issue, but thanks anyways :P
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
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...

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.
8)

Cheers :)

Posted: Wed Sep 27, 2006 7:43 pm
by Jenk
So what alternative do you suggest? Zend_Config_Config - Becomes Zend/Config/Config.php?

On the note of quick class ID - Misc is hardly descriptive.

Posted: Wed Sep 27, 2006 7:51 pm
by alex.barylski
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?
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:Also, now you are saying that the problem is that the names are too long
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.
Do you consider the long names a weakness or just a hassle
A weakness in design? Not all as the code would still be workable and scablable...but having to remember
This_Is_A_Class_That_Does_Just_A_Simple_Thing_And_Has_A_Very_Long_Name_to_Boot_No_Pun_Intended
Exaggerated as I did the first time, but clearly you don't see what I'm saying so I exaggerated again :P

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. :cry:

You arguments go like this (if I understand you correctly):
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.
Here are my arguments:

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 :)

Posted: Thu Sep 28, 2006 7:39 am
by Maugrim_The_Reaper
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.

Posted: Thu Sep 28, 2006 5:25 pm
by alex.barylski
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 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...

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... :P

If your interested in sharing ideas or swaping thoughts PM and I'd be glad to continue with you...publically...I'm done :)

Posted: Thu Sep 28, 2006 5:35 pm
by Christopher
Hockey wrote:but future scalability is hindered, by the fact the classnames share such a tight coupling with directory names...
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.

Posted: Thu Sep 28, 2006 9:02 pm
by alex.barylski
arborint wrote:
Hockey wrote:but future scalability is hindered, by the fact the classnames share such a tight coupling with directory names...
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.
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.

Posted: Thu Sep 28, 2006 9:27 pm
by Ambush Commander
Ermm... forgive me if someone mentioned this already, but why not create a compat/ directory that emulates old classnames/classpaths for compatibiliy?

Posted: Thu Sep 28, 2006 9:51 pm
by alex.barylski
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?
No one mentioned that yet (as far as I know) :P Everyone just argued and refused to see my point.

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 :)

Posted: Thu Sep 28, 2006 9:58 pm
by Christopher
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.
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.
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?
You are being shockingly practical :!: