Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21496 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 40565 invoked by uid 1010); 12 Jan 2006 19:21:27 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 40550 invoked from network); 12 Jan 2006 19:21:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jan 2006 19:21:27 -0000 X-Host-Fingerprint: 209.59.182.2 amplex.webserversystems.com Linux 2.4/2.6 Received: from ([209.59.182.2:54633] helo=amplex.webserversystems.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 0F/47-29075-63CA6C34 for ; Thu, 12 Jan 2006 14:21:26 -0500 Received: from whitecockade.com ([64.142.12.177]:61967 helo=[192.168.0.9]) by amplex.webserversystems.com with esmtp (Exim 4.52) id 1Ex80i-0000Nw-AK for internals@lists.php.net; Thu, 12 Jan 2006 14:21:24 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43C67431.9090003@prohost.org> References: <43C67431.9090003@prohost.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-ID: <3A366ACB-20D4-42C7-BBAE-46F643E3A91F@intuitivefuture.com> Content-Transfer-Encoding: 7bit Date: Thu, 12 Jan 2006 11:21:20 -0800 To: internals@lists.php.net X-Mailer: Apple Mail (2.746.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - amplex.webserversystems.com X-AntiAbuse: Original Domain - lists.php.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - intuitivefuture.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [PHP-DEV] Re: Named arguments revisited From: jared@intuitivefuture.com (Jared White) On Jan 12, 2006, at 7:22 AM, Ilia Alshanetsky wrote: > Aidan Lister wrote: >> 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. > > What exactly do you find lack about associative arrays? To put the shoe on the other foot, what exactly do you find lacking about named parameters so that you'd prefer to use the more syntactically complex and less sophisticated array method? Quite frankly, implementing named parameters is sort of a no-brainer; I understand a reluctance to implement it based on time/effort considerations, but for some of the core devs to actually defend not implementing it based on a design decision is weird. Why named parameters? Because like with normal parameters/arguments, you must specify required parameters. An associative array is not enforced by the language -- you have to manually check that the array has the required parameters and manually throw an error/exception. That's...stupid. Plus, with the array there is no language-based documentation for the parameters -- all that the function/method signature specifies is just one array parameter. That's also stupid. PHP is all about using a simple means to an end and getting the job done. Named parameters makes coding easier, not harder. So why defend keeping it out of the language? Regards, Jared