Boost logo

Boost :

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

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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at