[boost] Re: [Review] Named parameters library

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
>>> news:uekiyo6n5.fsf_at_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