I dislike this idea from the ground up. While I think having a legacy implementation is definitely worth while, it needs to be in core. So PHP6 would introduce the new syntax, and include the legacy functionality in as close to 100% backwards compatible way as possible. From there, we'd only remove the legacy functionality from core in 7 (which could be 4 or 5 years out).
We don't want to be in the same situation with 6 that python was in with 3, and perl was in 5. We want to encourage adoption. Having a PECL extension needed for adoption is not going to fly too well. But if we can add the new functionality and give people an easy migration path, adoption will be easier. It still may take years, but it will at least be fairly smooth as the majority of existing code will still work. Of course some BC breaks may be necessary (a-la what happened with PHP5), but they should be fairly localized and pretty easy to handle... And they should be justified (breaking BC for the sake of it, as with these legacy functions, would be a mistake)... My $0.02 at least. Anthony On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds <ajf...@googlemail.com>wrote: > This is an excellent idea. Full BC yet without legacy cruft. Old code runs > on legacy support extensions, new code doesn't need it. > On Jul 17, 2012 1:51 PM, "Leigh" <lei...@gmail.com> wrote: > > > > Basically, the current function library is moved to the legacy > > > namespace. The default setting is import the functions of the legacy > > > namespace into the root namespace for BC. But with that setting > > > turned off all the existing functions go away to be replaced with a > > > designed API, instead of a grown one, correcting the mistakes that > > > have accumulated over the years. > > > > Is there any reason why this cannot / should not be implemented as a > > PHP 5 compatibility extension? > > > > I think those who never want to use it (PHP 6 purists) shouldn't have > > to have their binaries bloated by legacy code. It would also mean that > > the legacy implementation can be developed away from the new core, and > > not have any (negative) influence on it. > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
