[boost] Re: [Review] Named parameters library

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 
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