Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21532 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6156 invoked by uid 1010); 15 Jan 2006 07:17:01 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 6140 invoked from network); 15 Jan 2006 07:17:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jan 2006 07:17:01 -0000 X-Host-Fingerprint: 144.136.4.14 CPE-144-136-4-14.vic.bigpond.net.au Received: from ([144.136.4.14:27001] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 54/A8-13436-BE6F9C34 for ; Sun, 15 Jan 2006 02:16:59 -0500 Message-ID: <54.A8.13436.BE6F9C34@pb1.pair.com> To: internals@lists.php.net Date: Sun, 15 Jan 2006 18:17:28 +1100 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <11370812947200000@9866357972520000.9866341568840000> <43C688AE.80403@php.net> <43C69B2A.8000802@php.net> <21.B4.29075.F75A6C34@pb1.pair.com> In-Reply-To: <21.B4.29075.F75A6C34@pb1.pair.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 144.136.4.14 Subject: Re: [PHP-DEV] Re: Named arguments revisited From: aidan@php.net (Aidan Lister) Ron Korving wrote: > Another nice use case is querybuilders: > > $query = buildQuery(select: $columns, from: $tables, leftjoin: $leftjoins, > limit: 10); > We've seen a large number of cases where named parameters would be extremely useful. To each case, there has been a half baked attempt to dismiss the usefulness of the purported design. For example, > If you have too many parameters that you want to start omitting > parameters when calling a function, its probably time to refactor. Refactor? If you have a number of required options to get a result, refactoring isn't going to change that. Also, > And if you have many parameters to functions you still need to look at > the definition (or documentation) to figure out what parameters the > function takes. It's not a big problem to look at the order at the > same time. That's not the point, at all. It annoys me that good points are being dismissed with such ridiculous counter-arguments. No one is suggesting that people shouldn't look at the definition. Nor that people have problems remembering parameter order (I do, but again, not the point). In fact, named parameters allows people to quickly look at the definition to see what options are available. This is one reason named parameters are an improvement on associative array parsing. The problem is when an option needs to be changed which just happens to be at the very end of the function signature, function calls start looking like this: foo(null, null, null, null, null, null, true); Anyway, enough rebuttal. I think it's now incredibly obvious that the wider community would like to see named parameters in PHP 6. Are the PHP group prepared to accept and implement a named parameters patch?