Re: PEAR2 package naming standards (namespace usage)

Travis Swicegood a écrit :

Actually, in a properly designed class, the logic of where the driver is located would be hidden from you unless you were injecting a custom one. In which, a properly designed class would again let you name it however you please, so long as it implements the proper interface. This is a red herring; you never have to touch that code.

Sure, I agree (and also agree with what pointed josh), sorry if I'm not clear enough, my point is on the structure of the namespace: pear2::<category>::<package>::<Class> pear2::<category>::<package>::<subpackage>::<Class> this way I can do: <?php use pear2::<category>::<package>; $a = new <package>::Class(); $b = new <package>::<subpackage>::Class(); ?> It's clean and saves me a lot of typing, I'm lazy ;) With the current proposal I *cannot* do this, because, if I understand correctly namespaces would be: pear2::<package>::<Class> pear2::<package_subpackage>::<Class>

I think it's worth re-iterating. One of the biggest hurdles PEAR1 poses to any new project is tracking multiple projects. One can argue that this is not important until they're blue in the face, but if people have a hard time getting it setup, they won't use it. We need to minimize those barriers as much as possible. To re-iterate all of the points that this RFC addresses: * it minimizes the directory structure complexity

I don't think this is a big issue.

* it allows svn:externals, git:submodules, etc., to track pear2 packages

I don't get it, the autoloader can handle this problem, no ? We could have a svn structure like pear1 cvs (ie: one directory per package, thus allowing svn:externals) and still have namespaces like: pear2::text::capcha pear2::text::capcha::numeral pear2::text::diff pear2::services::akismet etc... or am I missing something ? Anyway, as Alexey said, it's a subversion (or git or whatever) problem, we cannot make a decision for a third party program convenience.

* it clearly defines what is the class and what is the namespace (the path, to use David's example)

I agree on this, but this is just a "case" issue.

* it allows proper English to be used within that package

To me: "pear2::mdb2::driver::MySQL" (MySQL is the class) is as clear as: "pear2::mdb2_mysqldriver::Driver" (Driver is the class) (And to be honest, even clearer).

One additional concern that's been brought up to me privately is simplifying package names. For example, text_diff is really redundant. It could be named "diff" just as well, and that allows the developer to add binary diffs, token diffs, and any number of other cool things that aren't specifically text.

I think that one of the strength of pear1 is its categories but maybe I'm the only one ;) Take python for example: stdlib module naming is a mess, and they're fixing it in python 3000... (don't get me wrong I *love* python). see: http://www.python.org/dev/peps/pep-3108/#grouping-of-modules-done "Categorizing" is a good thing, even if it adds some verbosity, I think we should keep the idea in namespaces. -- David.