[boost] Re: [Review] Named parameters library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-11-16 14:53:09

"David Abrahams" <dave_at_[hidden]> wrote in message
news:u4qjqq4is.fsf_at_boost-consulting.com...
| Thorsten Ottosen <nesotto_at_[hidden]> writes:

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

but one can store a reference if that is beneficial.

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

you must be confusing move-semantics with this situation, or I'm missing
something.
there should be no difference between storing a temporary implicitly or
explicitly...it's
still there and still takes up stack-space no matter what. If the function
does return a reference, then
simply store that instead of copying the whole object.

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

if you have an object that wraps an algorithms somehow, you can just pass that
object around by its name. For example, you can pass the painter object around
and change state explicitly by p.set_hue( ... ); So the mecanism that is used
to document
intend does not disappear as it otherwise would.

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

IMO, any boost library should be able to answer why it is the best library for
the given task.
Sometimes its easy to do so; sometimes its hard.

| > - possible performance drop?
|
| Any method that requires stateful storage will incur a greater
| performance drop than building a struct of references.

not if you store big objects by reference. And that has been my point all
along.

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

Selfdocumenting code is a really fine goal; there are just other ways to do
it. My no vote
simple reflects that I don't the see the current library's benefit/problem
ratio as big enough.

For example, the self-documentation of

void paint( int luminance, int hue );

can be done in many ways.

#1 your library

paint( luminance = 42, hue = 10 );

#2 variables

int luminance = 42;
int hue          = 10;
paint( luminance, hue );

#3 objects
painter p;
p.set_luminance( 42 );
p.set_hue( 10 );
p.paint();

Adding to this, many editors can be pursuaded to show argument list so that
when you type "paint(", you get to
see the arguments which for some makes paint( 42, 10) ok.

The other issue related to default arguments, and not to self-documenting
function calls.

Currently it is really a pain in the *** to have an object with many default
arguments. Your library makes that managable; but I argue
functions with many arguments should be refactored since their level of
abstraction is getting too low; allowing many default arguments
juat makes the situation worse.

-Thorsten