Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21481 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 47432 invoked by uid 1010); 12 Jan 2006 06:25:47 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 47417 invoked from network); 12 Jan 2006 06:25:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Jan 2006 06:25:47 -0000 X-Host-Fingerprint: 66.216.66.81 mail.ionzoft.com Linux 2.4/2.6 Received: from ([66.216.66.81:53879] helo=mail.ionzoft.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 8B/C4-29075-A66F5C34 for ; Thu, 12 Jan 2006 01:25:47 -0500 Received: from JASONGARBER2 (207-255-4-232-static.aoo.pa.atlanticbb.net [207.255.4.232]) by mail.ionzoft.com (Postfix) with ESMTP id 62D258A4085; Thu, 12 Jan 2006 01:26:34 -0500 (EST) Date: Thu, 12 Jan 2006 01:25:42 -0500 X-Mailer: The Bat! (v3.64.01 Christmas Edition) Professional Reply-To: Jason Garber Organization: IonZoft, Inc. X-Priority: 3 (Normal) Message-ID: <157554660.20060112012542@ionzoft.com> To: Aidan Lister CC: internals@lists.php.net In-Reply-To: <56.50.29075.176B5C34@pb1.pair.com> References: <56.50.29075.176B5C34@pb1.pair.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Named arguments revisited From: jason@ionzoft.com (Jason Garber) Hello Aidan, I think named parameters would be a useful feature... I'll leave it at that. Here is a coding idea for you, in case you hadn't considered it... function highlight($text=NULL, $needle=NULL, $strip_links=NULL, ...) { is_null($text) && $text = SOME DEFAULT VALUE; is_null($needle) && $text = SOME DEFAULT VALUE; is_null($strip_links) && $text = SOME DEFAULT VALUE; ... } In that way, the user doesn't have to remember the default values, just the offsets. Best wishes with the proposal. -- Best regards, Jason mailto:jason@ionzoft.com Wednesday, January 11, 2006, 8:53:11 PM, you wrote: AL> 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 AL> In a simple highlighting function I wrote (which at 16k hits is probably AL> considered useful) I needed most of the following parameters: AL> $text AL> $needle AL> $strip_links AL> $case_sensitive AL> $whole_word_only AL> $simple_text_only AL> $highlight_pattern AL> $return_or_print AL> $use_xhtml AL> $tooltips_or_divs AL> I imagine any function dealing with html may use a significant portion AL> of these. Obviously some of these are for effect, but I think my point AL> is clear enough. AL> We've discussed other options at developers disposal like associative AL> arrays, setOpt and getOpt functions in a class, but again each have AL> their drawbacks and named parameters solve the problem elegantly. AL> Could we properly discuss the pros and cons of a name parameters AL> implementation - even if it's only to put the whole issue to bed once AL> and for all? AL> Best wishes, AL> Aidan