Re: BC solution for Alexey's good point :)

Hi! Forgive me Greg, but this is complete BS for the following reasons: 1) This is a solution to a problem introduced by a previous "clever" solution. Thus it is not needed if the "clever" solution is flushed down the toilet where it really belongs. 2) This kills the ability to run different (essentially minor) versions of package concurrently: the point that RFC supporters drool about. 3) MDB uses wrappers to go from two packages with completely different APIs, not to migrate from MDB 0.9.1.2.3.4.5 to MDB 0.10 And last but not least: 4) My good point was that if someone needs this BS then HE IS PERFECTLY CAPABLE OF CREATING CUSTOMIZED PACKAGES (Foo_v2) WITH CURRENT INFRASTRUCTURE. I just don't get why this s**t must be mandatory and why I should change my applications IF I DON'T NEED THIS "FUNCTIONALITY". This wasn't addressed at all. Clarification: I consider API changes like PHPUnit 0.6 -> PHPUnit 1.0 as different packages and fully support RFC for these. Greg Beaver wrote:

Hi all, Alexey raises a really good point - if there are only small BC breaks, the user is still forced to rename every single element in his/her use of the package in order to upgrade easily with the new BC RFC. I have a solution ripped from an offlist email by Josh Eichorn. A wrapper file can be provided that contains elements similar to this: <?php if (class_exists('MDB')) {

    trigger_error("Cannot use MDB_v2 wrapper: MDB 1.x is already in use", E_USER_ERROR);

} class MDB extends MDB_v2 { } define('MDB_ERROR_BLAH', MDB_V2_ERROR_BLAH); ?> Then, a user can simply change the require_once statements with a cut and paste: require_once 'MDB.php'; becomes require_once 'MDB/v2/MDB1wrapper.php'; The name is negotiable, in fact I don't care what it is called, just as long as the wrapper can be easily loaded. This system is already used quite successfully by DB users who wish to switch to MDB, and metabase users who wish to switch to MDB, which proves that the idea works in practice as well as in theory. With this addition to the RFC, there are no problems. If the user decides to totally migrate to MDB v2.x, he/she can do the work involved to search-and-replace MDB to MDB_v2 (case-sensitive) and MDB_ERROR to MDB_V2_ERROR, etc. Now, users who, like Daniel's example of the grocery store using HTML_TreeMenu for navigation, need not worry, because they can be guaranteed that the HTML_TreeMenu package will always work for them. If they hire some nerd later to fix up their site, he/she can migrate to version 2.x as HTML_TreeMenu_v2 easily enough, and use the wrapper very quickly if, for instance, they are only contracted for 5 hours of paid work to update the whole site.