From: David Abrahams (dave_at_[hidden])
Date: 2004-11-13 17:25:16
"Peter Dimov" <pdimov_at_[hidden]> writes:
> David Abrahams wrote:
>> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
>>> "David Abrahams" <dave_at_[hidden]> wrote in message
>>>> 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)
>>>> paint(1071, 10)
>>> again, you could just say
>>> painter p;
>>> p.set_hue( 1071 );
>>> p.set_luminance( 10 );
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk