[boost] Re: [Review] Named parameters library

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-15 14:46:35

Thorsten Ottosen <nesotto_at_[hidden]> 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