From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-11-15 10:01:30
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
> 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)
> 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
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
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()
would loose the defaults and explicit-naming, a significant drawback)
> > | It looks like you didn't really read through the library docs.
> > | 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
> 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
in the docs. The review manager had to mention bgl_named_parameters
So here's the situation: you believe named parameters is the thing;
> 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
benefits and a new set of drawbacks. I wouldn't conclude as you have
named parameters is the best solution.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk