Re: solution for BC breakage

Hi Daniel, Daniel Khan wrote: Why don't we implement a class loader method like PEAR::load($packageName [, $version]) This loader knows about PEAR's internal structure and so no user will ever have to know where a package is located in the filesystem. This is a decent idea, but becomes rather complex for sub files. Does PEAR::load() set include_path so that require_once 'MDB/drivers/mysql.php'; // (this is hypothetical) would work? I'm not sure this will be the best solution. I'm very much in favor of Tomas's suggestion. There would be no need for additions to the core, which is good, as new bugs cannot be introduced, and some semblance of simplicity is maintained :). The way this would work is: application/package #1: <?php // use Foo_Fighter1.x require_once 'Foo/Fighter.php'; require_once 'Foo/Fighter/Driver/blah.php'; // ... ?> application/package #2: <?php // use Foo_Fighter 2.x require_once 'Foo/Fighter2.php'; require_once 'Foo/Fighter2/Driver/blah.php'; // ... ?> In other words, the onus is on developers to provide a different package named Foo_Fighter2 - the PEAR website would be smart enough to know that this is indeed Foo_Fighter version 2.x, but the installer frankly wouldn't care as Foo_Fighter is really truly != Foo_Fighter2. By this I mean that if two packages can co-exist, they are by definition NOT the same package! Of course, packages often conflict with each other, and using both version 1.x and version 2.x of a package in the same application would still not work, but nobody wants that possibility, I hope :). In this way, no changes need be made to the installer, no changes need be made to the structure of package.xml, and developers need to do a little extra work, but it actually makes developing and fixing bugs on different versions much more intuitive, as you don't need to use CVS branches, but instead have separate source trees. Greg