"Peter Dimov" <pdimov@mmltd.net> writes:
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.
Yes, of course. I like the idea of a color abstraction. But often the parameters don't form a neat little package like "color."
Of course we have now restated the problem in terms of constructor parameters. Does the library support named constructor parameters, by the way?
Of course; an example of that usage is exactly what Thorsten was complaining about in the first place. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com