Re: PEAR2 package naming standards (namespace usage)

On Wed, Aug 27, 2008 at 3:59 PM, Joshua Eichorn <josh@bluga.net> wrote: > Baptiste Autin wrote: >> >> With the current proposal I *cannot* do this, because, if I understand >>> >>> correctly namespaces would be: >>> >>> pear2::<package>::<Class> >>> pear2::<package_subpackage>::<Class> >>> >> >> Joshua told me that I was allowed to have a class like: >> pear2::php_uml::xmi::Builder.php >> >> So I guess it means that you can have, like you need: >> pear2::<package>::<subpackage>::<Class> >> (stored into pear2/package/subpackage/Class.php) >> >> And why not: >> pear2::<package>::<subpackage1>::<subpackage2>::<Class> >> (stored into pear2/package/subpackage1/subpackage2/Class.php) >> >> Baptiste >> >> >> >> > > Thats not actually subpackage, its just a sub-namespace, but yes thats > allowed. > > The difference being that if your releases code as a subpackage then its > treated more or less like a new package. > Which means, if I may display another PEAR1 example, that the renderers for SDG would be pear2::structures_datagrid_renderer_html::Renderer or some-such. I agree that the factories are, of course, the way to go here but this still begs the question of why this is not classified under the pear2::structures_datagrid namespace. Let's put this another way. How will these packages be installed? Surely not like this: /usr/lib/php/pear2/structures_datagrid/ /usr/lib/php/pear2/structures_datagrid_renderer_html/ but like this: /usr/lib/php/pear2/structures/datagrid/ /usr/lib/php/pear2/structures/datagrid/renderer/html. Why the disconnect? -- Justin Patrin