"David Abrahams" <dave@boost-consulting.com> wrote in message news:uekiyo6n5.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> 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