Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21480 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91990 invoked by uid 1010); 12 Jan 2006 01:52:51 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 91975 invoked from network); 12 Jan 2006 01:52:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jan 2006 01:52:51 -0000 X-Host-Fingerprint: 144.136.4.14 CPE-144-136-4-14.vic.bigpond.net.au Received: from ([144.136.4.14:15597] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 56/50-29075-176B5C34 for ; Wed, 11 Jan 2006 20:52:50 -0500 Message-ID: <56.50.29075.176B5C34@pb1.pair.com> To: internals@lists.php.net Date: Thu, 12 Jan 2006 12:53:11 +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: [PHP-DEV] Re: Named arguments revisited From: aidan@php.net (Aidan Lister) Andrei Zmievski wrote: > On Jan 9, 2006, at 4:09 AM, 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. >> > > If you get to the point where your function has a dozen parameters, I > would suggest re-thinking the purpose and design of such a function, > because you are likely trying to make it do too much. > > -Andrei In a simple highlighting function I wrote (which at 16k hits is probably considered useful) I needed most of the following parameters: $text $needle $strip_links $case_sensitive $whole_word_only $simple_text_only $highlight_pattern $return_or_print $use_xhtml $tooltips_or_divs I imagine any function dealing with html may use a significant portion of these. Obviously some of these are for effect, but I think my point is clear enough. We've discussed other options at developers disposal like associative arrays, setOpt and getOpt functions in a class, but again each have their drawbacks and named parameters solve the problem elegantly. Could we properly discuss the pros and cons of a name parameters implementation - even if it's only to put the whole issue to bed once and for all? Best wishes, Aidan