Thorsten Ottosen <nesotto@cs.auc.dk> writes:
David Abrahams <dave <at> boost-consulting.com> writes:
"Thorsten Ottosen" <nesotto <at> cs.auc.dk> writes:
"David Abrahams" <dave <at> boost-consulting.com> wrote in message
ok, I don't see the simple object.set_XX() to cause any coupling either.
It doesn't cause any coupling. But it's uglier than what we're doing, and it requires state, and provides no advantages.
AFAICT, not more state than that already needed by the parameters of the function.
Yes, it requires more state. The value passed to set_XXX has to be stored somewhere.
One major problem with state (aside from stylistic concerns which I also consider valid) is:
f(table = create_a_table(), name = "boxes")
if create_a_table returns a vector, it can be passed by reference all the way through to f's implementation. With obj.set_table(create_a_table()), you have to store a copy of the vector.
why can't you store a reference?
Because you'd be storing a reference to a temporary, which would have evaporated by the time you get to actually initiate the call.
again, you could just say
painter p; p.set_hue( 1071 ); p.set_luminance( 10 ); p.paint();
Yes, but it's ugly, stateful, and comparitively easy to misuse. And it's not even the moral equivalent of having named parameters, as far as I can tell. You're worried about "making it possible" to write functions with >5 parameters, but a class with >5 setter functions that isn't really meant to act like an ordinary class
classes have many roles, its hard to say what constitutes "an ordinary".
but instead as a poor man's substitute for a function with named parameters is surely worse than just having the feature!
I'm trying to discuss alternatives without elevating one to be a superior feature.
It's not a question of which feature is superior, but of which one more directly expresses programmer intent. You can write loops with goto, but a looping construct is a better expression of that intent.
There is some overlap, but a class approach means that you can do the same operation except for feature X now = something easily. And you can pass the object around without using function<> or bind()
I don't see what those have to do with anything.
(which would loose the defaults and explicit-naming, a significant drawback)
Not true. Bind would not loose the explicit naming or the defaults. As for function<>, no alternative approach you can name would preserve them, either.
| 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.
Oh, please. Do you really think I haven't spent years thinking about and discussing alternative approaches for named parameters?
No, I believe you have done that.
However, I don't know what you're thinking and what alternatives you have been discussing. There is no mention of any alternatives in the docs.
I didn't think that it was important for the library docs to discuss alternative approaches. We have almost no discussion of alternative approaches in the body of any of our libraries' documentation. Yes, there are occasional rationales for specific design choices.
The review manager had to mention bgl_named_parameters himself.
So here's the situation: you believe named parameters is the thing;
It's _a_ thing.
I'm not convinced.
Okay, I can accept that, and will stop trying to convince you.
I already gave them in several ways: they make code more readable and to allow you to take advantage of default arguments without regard to parameter order.
And the drawbacks are
- wierd macro definition must be used for functions
No, it's not required. That's a shorthand.
- possible performance drop?
Any method that requires stateful storage will incur a greater performance drop than building a struct of references.
- advantage is removed when passing the object around via function<>
What object? Our approach just uses functions. You're the one who keeps wanting to introduce objects ;-) Mr. Gladyshev has suggested that named parameter support ought to be somehow merged with boost::function. We might consider that if the library is accepted.
- introduces forwardng problem
Also solves forwarding problem ;-). There's no problem at all if you just use named parameters.
- can potentially lead to large parameter lists
How?
That is enough for me to start looking for alternatives which have the same benefits and a new set of drawbacks. I wouldn't conclude as you have done, that named parameters is the best solution.
To what? Named parameters aren't as much a solution to anything as an expressive programming idiom that has been used very successfully in all kinds of languages and environments. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com