Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21452 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22221 invoked by uid 1010); 9 Jan 2006 12:09:38 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 22206 invoked from network); 9 Jan 2006 12:09:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Jan 2006 12:09:38 -0000 X-Host-Fingerprint: 144.136.4.14 CPE-144-136-4-14.vic.bigpond.net.au Received: from ([144.136.4.14:13976] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id D5/B6-19414-18252C34 for ; Mon, 09 Jan 2006 07:09:37 -0500 Message-ID: To: internals@lists.php.net Date: Mon, 09 Jan 2006 23:09:51 +1100 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 144.136.4.14 Subject: Re: Named arguments revisited From: aidan@php.net (Aidan Lister) Jared White wrote: > Named arguments are absolutely essential for using PHP as a solid > templating language, and, in fact, they also greatly enhance code > readability for complex method calls of in-depth APIs. I agree. As useful functions tend to increase in complexity over time, often so does the number of parameters. It soon gets to the point where function calls look like: foo(true, false, false, false, false, true) The rest of the parameters being required to be supplied, with their default value, when the user is only interested in changing the last option. Sure, you can fall back to associative array parsing. However, I feel it lacks the rigor that named parameters can give. Named parameters also give a clean method for the user to see the available options, rather than reading through source code. I'd really like this issue to be given more consideration. It's been brought up consistently over the last couple of years, in some cases rather passionately (I believe someone wanted to fork PHP over this a while back). We have a long time before a PHP6 release, this is the ideal time to discuss implementation. Kind regards, Aidan Lister