If there's this big conflict between BC breaks being bad because they discourage adoption and make old code unusable on the one hand, and good because they allow many things to be cleaned up and progress to be made, then why not pursue a three-pronged approach: 1. BC breaks are made wherever it makes sense to make the best PHP 6.0 possible 2. Near-full backwards compatibility is kept as an extension included with the core (a long way down the road, it can be deprecated, moved to PECL, dropped altogether, etc., once the migration is complete and old code has mostly been ported) 3. Build a high-quality tool to convert code automatically to the greatest extent possible
One last suggestion is that in order to keep legacy 5.x code (using the compatibility extension) and 6.0 code interoperable, 6.0 should use a slightly modified version of the open tag, for example <?php6 or <*php, etc. This satisfies several desires: we don't want an extra line of boilerplate code like 'use PHP 6' to be required in every source file, we want a PHP 5 file to run without modification, and we want a PHP 6 file to be able to include a PHP 5 file without modification, but we don't want PHP 6 to have to be a superset of PHP 5. On Wed, Jul 18, 2012 at 3:27 PM, Kris Craig <kris.cr...@gmail.com> wrote: > On Wed, Jul 18, 2012 at 12:09 PM, Andrew Faulds <ajf...@googlemail.com>wrote: > >> Kris, I'd love to break BC a lot and fix things, but it would seriously >> slow adoption. Fixing *bugs* has stopped people upgrading, imagine how they >> would react to non-bugs being changed. >> >> > I agree with your point. I guess my thinking is that this is an > unavoidable cost of progress, at least on a major version change. Given > that the alternative is an increasingly stagnated codebase, IMHO the cost > of slower adoption would be the "lesser of two evils." > > --Kris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
