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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
