To avoid BC breaks we should try to avoid major syntax changes. We could make new applications "hide" legacy though, something like "use new;" which would remove deprecated and legacy functions from the global namespace. On Jul 18, 2012 12:16 AM, "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 >>>> >>>> >>>> > >
