Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-11-15 10:01:30

David Abrahams <dave <at>> writes:

> "Thorsten Ottosen" <nesotto <at>> writes:
> > "David Abrahams" <dave <at>> 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)
> 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()
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'm not

> 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
named parameters is the best solution.


Boost list run by bdawes at, gregod at, cpdaniel at, john at