Re: [boost] Re: [Review] Named parameters library

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-13 10:28:55

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. 
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 );