Re: PEAR2 package naming standards (namespace usage)

Howdy all... On Aug 27, 2008, at 2:01 PM, David Jean Louis wrote:

Hmm... see my "drivers" or "adapters" example in my previous mail. I don't want to type the same path every time, and I don't want to have a "use" statement for each class I instanciate... Let's take the example of Services_Shipping: In reply to Kristopher, you mention the namespaces would be: pear2::services_shipping_ups::Driver pear2::services_shipping_dhl::Driver IMO this is wrong (and even cause a conflict if you want to instanciate the two drivers, unless you use the "as" construct).

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. 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 * it allows svn:externals, git:submodules, etc., to track pear2 packages * it clearly defines what is the class and what is the namespace (the path, to use David's example) * it allows proper English to be used within that package 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. This RFC specifically does not require a particular schema for a package name. pear2::diff would be perfectly valid if a collective decided to name it that way. That does remove a key bit of metadata from the package name to allow proper categorization on the pear2.php.net website. We're still working out exactly how that will be handled, but it will most likely be handled via a new file within the root of the package directory that contains such information. -T