On 2/28/2011 8:48 PM, Andrei Alexandrescu wrote:
On 2/28/11 6:03 PM, Jonathan M Davis wrote:
The more I think about this, the more I'm against the idea of named
arguments.
I think you have been blessed to work with only small, clean APIs.
Certain domains definitely promote large argument lists. Though the
designs could certainly be refactored to e.g. group parameters into
separate objects, it's overkill to do that. I'm afraid sheer experience
is showing that your counterarguments are not based.
Andrei
Agreed. I don't know how many times, when designing an API, I've
considered making something configurable and instead just hard coded it
to avoid bloating things with yet another regular (must be passed
in-order) function argument or (if I put the options in a struct) yet
another type. Besides, using structs to hold options requires
boilerplate for the user of the library. What would you rather write?
A:
Options options;
options.someOption = someValue;
fun(mandatoryArg1, mandatoryArg2, options);
B:
fun(mandatoryArg1, mandatoryArg2, someOption = someValue);
The beauty of named arguments with defaults is that they allow you to
make things configurable with as little boilerplate code as possible for
the library writer and as little boilerplate as possible for the user in
the case where such configurability isn't needed.
