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 <[email protected]>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" <[email protected]> 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 <[email protected]
> >> >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" <[email protected]> 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