Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80241
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
Message-ID: <54AC3D31.1070200@gmail.com>
Date: Tue, 06 Jan 2015 19:53:21 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <54AB0A10.4010709@gmail.com> <D75E841E-7D75-4E7C-A234-904FFB1C15DC@ajf.me> <54AB0F3A.5020606@gmail.com> <06711056-CC82-41A6-BED9-FB87450C63BE@ajf.me>
In-Reply-To: <06711056-CC82-41A6-BED9-FB87450C63BE@ajf.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Parameter skipping, take 3
From: rowan.collins@gmail.com (Rowan Collins)

On 05/01/2015 22:35, Andrea Faulds wrote:
> If the default values are obvious and intuitive, as they should be, you don’t need “default”.

It's not always a case of not knowing what the default values are; 
sometimes it's a case of not knowing - and not wanting to worry about - 
what they might be in the future.

For instance, you might have an integer parameter representing some kind 
of cost-benefit tradeoff, with a "best practice" value as default, which 
happened to be the second of 3 well-defined parameters. To specify the 
third parameter, you need some way of saying "I'll accept the best 
practice for the second parameter, thanks".

There are a few options we can consider:
- You just hard-code the current documented value, leaving a comment 
that you have no idea what it means, or whether it might change. Clearly 
not optimal.
- The library allows some special-case value, such as NULL, to be 
passed. Not particularly readable, because it's not clear what NULL 
means in this context, or whether you've just messed up and it will be 
coerced to int(0). On the other hand, allows calling with a variable set 
to NULL (or other magic value) to select the default behaviour at run-time.
- The library defines a constant containing the default value, such as 
DEFAULT_FOO_COST. More readable, but relies on the library author having 
a good naming convention so that you don't have to keep going to the 
manual to find it.
- The proposed "default" keyword. More explicit than NULL, supported 
out-the-box without any effort on the part of the library author, lets 
you get on with your job. On the other hand, doesn't address the case 
where you want to select the default at run-time, e.g. foo('bar', 
$_GET['cost'] ?? default, 'baz') doesn't work; this is however true of 
existing optional parameters, it's just that they can only come at the 
end of the list.


> I’m not sure if this RFC actually would make such functions that much less painful. For functions with a lot of default parameters, telling them apart is key. Seeing “NULL, FALSE, FALSE, 0, NULL” may orient the user better when scanning a parameter list than “default, default, default, default, default” would.

A list of all defaults is clearly a straw man, since it would be a daft 
use of this feature. However, "10, null, default, 0" is clearer in its 
intent than "10, null, false, 0" - the 1st, 2nd and 4th parameters have 
been specifically chosen by the programmer, while the 3rd is left to the 
implementation to choose.


Named parameters do seem to offer a solution to a lot of the same use 
cases, but they have their drawbacks too - for instance, currently, 
parameter names are implementation details private to the function, and 
a straight implementation of named parameters would make them public 
overnight. However, as Stas says, the two mechanisms can coexist and 
complement each other, and if we get both it can be left to a matter of 
personal taste or style guides.

-- 
Rowan Collins
[IMSoP]