RE: [PEAR-DEV] [PEAR2 CS] Channel in paths

> Not necessarily. The package names must be unique to the channel, but > that doesn't mean that the PHP files within the foobar.com/Config > package aren't prefixed with namespace FooBar; class Config ... or > class FooBar_Config, and could certainly be used at the same time as > baz.net/Config class Baz_Config. Namespaces or class prefixes are irrelevant if the filenames are in conflict, aren't they? Installation would fail because of them, not due to (non-)conflicting class names. >> The only scenario where the current setup helps is if these packages, while >> naming themselves in this way also put themselves in a vendor named folder >> that is different across the channels. So I guess the real question is do >> they do just that? > > I'm sure we'd see a mix of both. > > If they're not using a vendor prefix or unique class names there's no > possibility of using them together, regardless of what Pyrus does. Wait... does Pyrus actually detect the (fully qualified) class names rather than the file names? I thought it compares the specified mappings from the package.xml with the folder structure of the PHP folder, and that inherently, that's the important thing here. That even if you have two differently named classes, they can't be used together if their package.xml files want the same filenames. If Pyrus automatically resolves any filename conflicts based on the fully qualified class name, then yeah, this wouldn't be an issue, and I can clearly see how channel folders would help. If it doesn't do that, then channel folders remain useless except in the above scenario. However, if an author is wise enough to put a vendor prefix in their PHP folder so that they're not in conflict there (even though no standard requires them to), I think it should be expected of them to be wise enough to do the same for other folders they're interested in. And if they aren't wise enough, the end user would suffer with or without channel folders. > What Pyrus is doing effectively namespaces the data/docs/test files > (on the filesystem) using a simple map. Within any code that > references these files, it's a matter of simply: > <?php > $data = file_get_contents(__DIR__.'/../data/foobar.com/Config/config.ini'); > // - vs - > $data = file_get_contents(__DIR__.'/../data/Config/config.ini'); > > Which I don't see as an obstacle for adoption of Pyrus or PEAR2. "Obstacle", no. Just an annoyance (you know, like bureaucracy). Why make it complicated if it can be simple? :-)