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