I'm wondering if we could include method overloading. Will be pretty nice mixing it with scalar type hinting or scalar values as objects
On Wed, Jul 18, 2012 at 11:27 AM, Andrew Faulds <ajf...@googlemail.com>wrote: > 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 > >>>> > >>>> > >>>> > > > > > -- Atenciosamente, Rafael Kassner
