It's possible, but we have to write too much code just to identify all possible overloads. If methods are overloaded by their signature, surely the PHP code will be more clean.
Well, I'm just wondering if it is possible without start a war, I'm not sure how expensive it could be. On Wed, Jul 18, 2012 at 1:58 PM, Andrew Faulds <ajf...@googlemail.com>wrote: > 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 >> >> -- Atenciosamente, Rafael Kassner
