Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49940
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain l-i-e.com designates 67.139.134.202 as permitted sender)
Message-ID: <988651dd53129fdfd1acb905c8161e95.squirrel@www.l-i-e.com>
In-Reply-To: <AANLkTi=VerH9yhv7+sSyvbzNp3fmkW+NFvvc2zgEu5Av@mail.gmail.com>
References: <AANLkTi=VerH9yhv7+sSyvbzNp3fmkW+NFvvc2zgEu5Av@mail.gmail.com>
Date: Wed, 20 Oct 2010 11:06:11 -0500
To: internals@lists.php.net
User-Agent: SquirrelMail/1.4.21 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] Skipping of defaulted parameters.
From: ceo@l-i-e.com ("Richard Lynch")

On Wed, October 20, 2010 6:58 am, Richard Quadling wrote:
> foo(10,, 30); // Parse error.

I thought this used to work...

> I would argue that by having a null in the arguments, the intent is to
> NOT supply a value and have the default value used in the function.

Unfortunately, no.

There are times when I want to over-ride the default, and shove NULL
in as the value...

> 1 - Do nothing in core and implement is_null() checking to reinstate
> the default value.

I believe that this is probably Best Practice in current PHP.
Validate your incoming parameters consistent with the intent of the
code-base in question.

> 2 - Allow null to be supplied and have the default value be used for
> the argument.
>
> foo(10, null, 30); // would output 10, 2, 30

-1

> 3 - New keyword of default or void to specifically indicate the intent
> to use the default value for the argument.
>
> foo(10, default, 30); // would output 10, 2, 30

This seems reasonable to me.

> 4 - Allow missing arguments to default.
>
> foo(10,, 30); // Parse error.

Also reasonable.

I'd even say both 3&4 together are in keeping with PHP spirit, to
allow the lazy scripters to use 10,,30 and the formal developers to
use DEFAULT.

> Option 4 would probably be the worse one to go for. Looking any number
> of languages that support defaults and you will see code like ...
>
> someFunction(param1,,,,,param7,,,,param11)

It does get ugly fast for large numbers of arguments...
But any function with more than a handful of arguments is already
asking for trouble...

At that point you should be passing in a data structure / instance /
array or something other than so many parameters.

Perhaps a constant like PHP_DEFAULT rather than a new "keyword"?

> But using something like _ (yep, underscore), could be a solution here
> [4].

Icky. :-)

> Option 2, after probably having to reject option 3, would be my
> choice. I want null to REALLY mean nothing. Just like it would be in
> foo(10).

Alas, NULL behaves more like an actual value sometimes, depending on
which functions you use...
isset versus array_key_exists, for example.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE