For a new version to be successful from a marketing perspective, there has to be such a thing as "good old code."
Just as there are PHP 4 apps that are basically sound and maintainable code and require only a few reasonable changes to run well in PHP 5, that needs to be true for the transition to 5 to 6. Otherwise it just won't be accepted as "PHP" by most people. "If I have to start from scratch, I guess I'll just use Ruby" would be a very reasonable response (: I do like the idea of pseudo-objects with methods as a way to create much cleaner APIs for strings and arrays, but the legacy APIs need to stick around. On Tue, Jul 17, 2012 at 7:16 PM, David Muir <davidkm...@gmail.com> wrote: > Took the words from my mouth. Removing legacy support is a terrible idea for > PHP6. It makes it impossible to write forwards compatible code that > currently runs in PHP5. Even having it optional is a bad idea IMO since it > will fragment PHP hosting. Some will be able to run PHP6 only (no legacy), > some will be able to run PHP5+ but will still be marketed as PHP6. Makes it > that much harder to know if your code will run on a client's server. > > David > > On 18/07/12 00:04, Anthony Ferrara wrote: >> >> 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 >>>> >>>> > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
