[boost] Re: [Review] Named parameters library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-11-13 07:18:17

"David Abrahams" <dave_at_[hidden]> wrote in message
news:uekiyo6n5.fsf_at_boost-consulting.com...
| "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
|
| > I think it should not be accepted. My main motivation is that I
| > think it promotes an unsound growth in function interfaces.
|
| Like having support for derivation promotes an unsound reliance on
| implementation inheritance and support for operators promotes abuse
| of operator overloading?
|
| Features don't promote practices.

I'm not sure I agree. I can just imagine all those C++ programmers who now
thinks
its cool to have functions with +5 parameters--afterall a respected library
like boost
has this cool library that allows it. So the fact that the feature exists and
is part of boost
will send the wrong message IMO.

| > I also miss a comparison of other techniques (eg. bgl_named_params,
| > named_constructor_pattern)
|
| I don't know about the latter.  Never heard of it.  But I'm guessing
| you're talking about something like:
|
|        f(slew_is(.799), score_is(55))
|
| If so, either it allows arbitrary parameter ordering and aside from
| the use of () instead of = its advantages are equivalent to those of
| our library, or it does not, and our library offers the advantage of
| freeing the user/reader/maintainer from having to remember parameter
| order.

yeah, doesn't the bgl solution do that too?

| > to do the same and an good explanation why this approach is
| > superior.
|
| This approach is superior to bgl_named_params in part because it
| avoids undue coupling and dependency in a library design.

| While writing this book, we reconsidered the interface used for named
| function parameter support. With a little experimentation we
| discovered that it's possible to provide the ideal syntax by using
| keyword objects with overloaded assignment operators:
|
|   f(slew = .799, name = "z");
|
| Not only is this syntax nicer for users, but adding a new parameter
| name is easy for the writer of the library containing f, and it
| doesn't cause any coupling.

ok, I don't see the simple object.set_XX() to cause any coupling either.

| > Let me elaborate.
| >
| > 1. Clearly, this is not nice
| >
| > window* w = new_window("alert", true, true, false, 77, 65);
|
| 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();

| > However, the amount of work needed to code parameters for this is
| > quite large.
|
| Really?  Did you compare how much work it would be to use
| BOOST_NAMED_PARAMS_FUN vs. what you're suggesting below?

I think I read the tutorial and that function was not mentioned in there, was
it?

| > A simple, effective way is just to do it like this:
| >
| > window* w = new_window("alert");
| > w->set_resizable( true );
| > w->set_height( 77 );
| > ....
|
| How would you apply that idiom to the algorithms of the Boost Graph
| Library?

make a class like this:

class  bellman_ford_shortest_paths_executor
{
    // one variable for each paramter, possibly using optional to save
    // performance
    void set_weight_map( weight_map& );
    void set_distance_map( distance_map& );
    ...
    execute( Graph& g, size_t n );
};

Depending on how it is designed, you can also pass such an object around
wihout relying on function<> and you might be able to query about the
execution
context.

Alternatively, some of the last N optional parameters should be
encapsulated in some new concept; it might even turn out that
this concept can be used many places and will give the library an increased
abstraction-level.

| > and you might provide chaining to make it more concise. In addition
| > there is no forwarding problems and you might have these functions
| > anyway.
|
| What do you mean by "you might have these functions anyway?"

I would expect a window class to have a set_height() function no matter what.

| >
| > 2. what happens, then, if I don't have an object, but a free-standing
| > function?
|
| That's the main use-case of our library!

yet you show the construction of an object of type window.

| >     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
|
| It looks like you didn't really read through the library docs.  You
| just use the library in the normal way.

I know, but I'm discussing alternatives...something I think the authors of the
library should do
before submitting.

| > about functions when they start having more than 3-4 arguments;
| > there is almost always some abstraction lurking just waiting to be
| > done.
|
| Maybe so, but there are plenty of other good arguments for named
| parameters.

What are they?

-Thorsten