Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60189 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 65225 invoked from network); 18 Apr 2012 13:16:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Apr 2012 13:16:08 -0000 X-Host-Fingerprint: 208.107.13.98 host-98-13-107-208.midco.net Date: Wed, 18 Apr 2012 09:16:05 -0400 Received: from [208.107.13.98] ([208.107.13.98:24266] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C5/AB-03614-59EBE8F4 for ; Wed, 18 Apr 2012 09:16:05 -0400 Message-ID: To: internals@lists.php.net References: <4F8DF4B1.2040307@sugarcrm.com> User-Agent: slrn/pre1.0.0-18 (Linux) X-Posted-By: 208.107.13.98 Subject: Re: [RFC] skipping optional parameters From: weierophinney@php.net (Matthew Weier O'Phinney) On 2012-04-17, Stas Malyshev wrote: > One of the annoying things I've encountered in working with PHP was > dealing with functions having long optional parameter lists, especially > if you need to change only the last one - you have to copy all the > defaults. Full named params implementation would solve it, probably, but > before we have that here's an easier solution for part of the problem: > > https://wiki.php.net/rfc/skipparams > > Basically, it allows you to do this: > > create_query("deleted=0", "name",,, /*report_errors*/ true); I actually had a need for either this or named parameters this past week, and as such would love to see one or the other in place. While I'd personally prefer named arguments, this approach would work in most places I've needed them. My one comment, which others have raised, is readability of multiple commas -- TBH, at first glance it has the appearance of a mistake. I think those suggesting a keyword such as "default" make a good point in this regard -- it makes it 100% clear that you want the default value for the argument in that position. This also presents an improvement over current usage, as you're not hard-coding values in your function calls themselves -- particularly as the defaults could change in future refactors. -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc