Re: Re: dependencies and applications

Stefan Neufeind wrote:

On 20 Aug 2003 at 20:59, Greg Beaver wrote:

Perhaps a transition - pear/MDB.php will still be available, but removed in a later date and replaced with a file that throws a warning before including pear/MDB/2.0/MDB.php (or whatever the latest version is) so that it still works, but displays a warning?

Might be an idea. Although it's a big step it seems the need for such a solution is there, right? This could in one step be done when we also take the other proposal into consideration that require_once 'pear/Net/something.php' should be used instead of require_once 'Net/something.php' right? Maybe a hard break in PEAR 2.0 implementing all this (and forgetting about all that has been up to now) is not an ideal solution? How about implementing this in 1.3 or 1.4 but storing the files both in MDB/MDB.php and pear/MDB/2.0/MDB.php? It would make sence to do such here would be the contents of MDB/MDB.php:

<?php trigger_error('WARNING: use require_once "PEAR/MDB/2.0/MDB.php" for the most recent version. require_once "MDB/MDB.php" is deprecated', E_USER_WARNING); require_once PEAR/MDB/2.0/MDB.php; ?> This would result is extremely hasty compliance. The only issue is that ALL PEAR releases would have to be modified the instant that PEAR 1.3 hit the market. Any release that contains internal require_onces would cease to work. file PEAR/PackageFileManager.php for instance, requires the internal file PEAR/PackageFileManager/CVS.php. Instead of: require_once 'PEAR/PackageFileManager/CVS.php'; it should use a relative path: require_once dirname(__FILE__) . '/CVS.php'; This will also speed up searching through include_path for files with many includes. However, any external dependencies would also need to be evaluated and re-worked - it's a huge undertaking. However, it would also be an easy way to determine which packages are orphaned :). Regards, Greg