That would be cool, but couldn't you just detect argument types? On Jul 18, 2012 5:55 PM, "Rafael Kassner" <kass...@gmail.com> wrote:
> 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 > >
