Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21542
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <44.80.13436.1035AC34@pb1.pair.com>
To: internals@lists.php.net
References: <11370812947200000@9866357972520000.9866341568840000><43C688AE.80403@php.net><FA4F8C63-2B68-4265-BDDF-6F8BFB5040B9@gravitonic.com><43C69B2A.8000802@php.net><21.B4.29075.F75A6C34@pb1.pair.com><54.A8.13436.BE6F9C34@pb1.pair.com><43C9FF01.1060008@lerdorf.com><7.0.1.0.2.20060115111835.0531d810@zend.com><43CA25CD.2040408@lerdorf.com> <7.0.1.0.2.20060115135052.05c1b848@zend.com>
Date: Sun, 15 Jan 2006 14:49:38 +0100
Lines: 55
Subject: Re: [PHP-DEV] Re: Named arguments revisited
From: r.korving@xit.nl ("Ron Korving")

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