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.
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?
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. 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() (which would loose the defaults and explicit-naming, a significant drawback)
| 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. The review manager had to mention bgl_named_parameters himself. So here's the situation: you believe named parameters is the thing; I'm not convinced.
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 - possible performance drop? - advantage is removed when passing the object around via function<> - introduces forwardng problem - can potentially lead to large parameter lists 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. -Thorsten