Re: [boost] Named params (was Re: Boost.MPI accepted)

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-09-23 15:16:43

Michael Walter wrote:
> On 9/23/06, Oleg Abrosimov <beholder_at_[hidden]> wrote:

 > Anyway, as I remember from D&E book there was a proposal to add named
 > params to the language, but it was rejected because of named params
 > encourage procedure-style programming and C++ was positionad as a OO
 > language. Of course, now it is positioned as a multiparadigm language,
 > but priorities remain the same: OO is preferred over procedural in C++.
 > or may be I'm missing something?

The entire STL is about as far from OO as one can imagine, so I'd say so. 
Smalltalk supports positional parameters and it's about as 'pure OO' as you 
can get.

>> The solution with auxiliary structure for parameter bundling is just
>> slightly more verbose, but
>> 1) it is exact (it is hard to interpret in a wrong way)
>> 2) it doesn't pollute namespace with parameter names
>> 3) instance of params structure can be reused many times reducing code
>> duplication/bloating.
>>
>> Sorry for so long opus, but I really wonder why David Abrahams and
>> Daniel Wallin put so great effort in the parameter lib. I can not see
>> it's advantages.
> 
> Problems with your approach include:
> 
> a) parameter values are copied
> b) parameter values need to be default-constructable (into a valid state)
> c) you cannot check whether mandatory parameters are supplied at
> compile-time (I believe)

I'll put it another way.  As software complexity has increased the number of 
options one might need to configure a particular class or function can become 
quite large.  Most of these options will typically have appropriate default 
values and hence won't need to be user specified.  However, making a set of 
overloads with positional parameters in combinations that make sense may be 
difficult or impossible.  Sure, you can make intermediate types, but really 
that's just a bit of noise that detracts from the users purpose.  Named 
parameters provide for code clarity where positional parameters cannot.

As an example, in date-time with the formatting facets there's all sorts of 
strings (month names, week names, infinity names) and other options that the 
user might want to override the defaults. Typically a user wouldn't override 
all of these, just a few.  Currently the library doesn't provide constructors 
that allow the user to override the options on construction -- it's just not 
reasonable with positional parameters and overloading.  Rather, they have to 
construct and then modify.  This is, in my view inferior -- I'd rather have an 
immutable facet type which handles all the overrides at time of construction.

This is enough of an issue that other languages have seen fit to incorporate 
this directly into the language -- Ada, Smalltalk, Objective-C to name a few. 
In other languages this is a proposed feature

http://dev.perl.org/perl6/rfc/57.html
http://www.mozilla.org/js/language/es4/rationale/named.html

In the meantime, perl 5 coders use conventions with hash data structures to 
accomplish what the perl 6 language feature would do.  It's an extremely 
common idiom in perl code.  Ruby, Python and other 'hot' languages all have 
ways to do this as well.

I, for one, am happy they have made the effort to provide a common way to do 
this in C++.  It's even more amazing to me that their's virtually no loss of 
efficiency.  It's only thru this sort of experimentation and effort that 
programming practices can be improved. I'd eventually like to see a language 
feature, but that's a different discussion....

Jeff