Michael Walter wrote:
On 9/23/06, Oleg Abrosimov <beholder@gorodok.net> 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