Re: Re: Named arguments revisited

Zeev, I agree with you that if this is implemented throughout the engine, it would actually not make things better. Some people will be doing strpos(needle: $needle, haystack: $haystack) and others will be doing strpos($haystack, $needle) and PHP will grow to a situation where half the people are doing A and half the people are doing B. I fear that would be very much for the worse. So, personally, I've come to the conclusion that it would be best if it existed as a userland feature only that people can use for those occasions where it might actually be useful. - Ron "Zeev Suraski" <zeev@zend.com> wrote in message news:7.0.1.0.2.20060115135052.05c1b848@zend.com... > At 12:37 15/01/2006, Rasmus Lerdorf wrote: > >Zeev Suraski wrote: > >>At 09:51 15/01/2006, Rasmus Lerdorf wrote: > >>>Aidan Lister wrote: > >>>>Are the PHP group prepared to accept and implement a named > >>>>parameters patch? > >>> > >>>As far as I am concerned it would depend on the patch. If you can > >>>come up with a way to do it with requiring rewriting all 4000+ > >>>functions out there, go for it. > >>As Andi said, that's hardly the big issue (we could have provided > >>it as a userland feature, not applicable to internal functions, or > >>applicable to just a small subset of them). > >>The big issue is whether or not we want that feature in the > >>language, and the answer appears to be no. > > > >Well, having half of a feature like that by only making it work in > >some places is what I think many folks are against. I don't think > >the answer is no if we had a clean and consistent way to implement > >it. I would certainly be all for it in that case. > > Ok, so we're split. I actually don't think it's a must to have all > functions adhere to this new method of calling (I don't think it's > necessary, but even if it was - it's probably just a few days of > work). It's definitely not the implementation which is the problem, > as with other cases, we have enough bright people on board here that > could figure it out if we wanted to go ahead with it. > > It's adding another core level feature that's useful in very rare > cases, and that adds another layer of complexity, that is the problem > in my (and many others') opinion. And it becomes even much worse if > we support it throughout the entire language, as it means it'll > become popular not only in these rare cases where it's really useful, > but throughout everyday usage (as is the case with about anything, > some people prefer one way of doing things, and others prefer another). > > Thankfully, regardless of the reasoning, the bottom line is no. > > Zeev