David Abrahams wrote:
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uekiyo6n5.fsf@boost-consulting.com...
True, but sometimes it is appropriate. Even then, you only need two parameters whose order is not obviously dictated by function to justify the use of a named parameter interface:
paint(hue = 1071, luminance = 10)
vs.
paint(1071, 10)
again, you could just say
painter p; p.set_hue( 1071 ); p.set_luminance( 10 ); p.paint();
Yes, but it's ugly, stateful, and comparitively easy to misuse. And it's not even the moral equivalent of having named parameters, as far as I can tell. You're worried about "making it possible" to write functions with >5 parameters, but a class with >5 setter functions that isn't really meant to act like an ordinary class but instead as a poor man's substitute for a function with named parameters is surely worse than just having the feature!
void paint( color const & c ); has the advantage that you can return a 'color' from a function or store it. Of course we have now restated the problem in terms of constructor parameters. Does the library support named constructor parameters, by the way? The equivalent window example would be window_desc wd = window_desc() .width( w ) .height( h ) .color( c ) .event_handler( e ); window_ptr pw = create_window( wd ); Again, if all your windows have width w and height h, you can extract this common part into a function: window_desc my_desc() { return window_desc().width( w ).height( h ); } and then use window_desc wd = my_desc() .color( c ) .event_handler( e ); window_ptr pw = create_window( wd );