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

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-11-12 20:59:26

> As always, please remember to clearly state whether you believe the
> library should be accepted into Boost.
> --------
> I think it should not be accepted. My main motivation is that I think it
> promotes an unsound
> growth in function interfaces. I also miss a comparison of other techniques
> (eg. bgl_named_params, named_constructor_pattern) to do the same and an good
> explanation why
> this approach is superior.
> 
> 
> Let me elaborate.
> 
> 1. Clearly, this is not nice
> 
> window* w = new_window("alert", true, true, false, 77, 65);
> 
> However, the amount of work needed to code parameters for this is quite large.
> A simple, effective way is just to do it like this:
> 
> window* w = new_window("alert");
> w->set_resizable( true );
> w->set_height( 77 );
> ....
> and you might provide chaining to make it more concise. In addition there is
> no forwarding problems and you might have these
> functions anyway.
> 
> 2. what happens, then, if I don't have an object, but a free-standing
> function?
>     a) wrap the function in an object
>     b) do as in http://www.boost.org/libs/graph/doc/bgl_named_params.html
>     c) provide overloads of functions that pack related parameters together or
> simply add defaults

In my tiny toy library, any function can be assigned
to a named parameters functor with a simple declration.

http://tinytl.sourceforge.net/#func_named_params_function

However the syntax for invoking it is not very pretty.

cw( cw.arg<style>(3) );
cw( cw.arg<title>("hi") );

instead of
cw( title = "hi" );

I was going to combine boost::named_params with
my named functors (in some way at least)
but never got around it... it is still on my list.

I agree that the all these steps from #2 just to make
a named wrapper is a bit excessive and probably
unnecessary.

> 
> I must admit I'm a bit sceptical about functions when they start having more
> than 3-4 arguments; there is almost
> always some abstraction lurking just waiting to be done.

If you have named parameters with default values, why not...

Eugene