[boost] Re: [Review] Named parameters library

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-16 20:05:58

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

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

You're 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.

Yes, but your scheme requires copying that temporary into a new
object, where it is stored again.  The proposed library allows a
reference to be bound to the temporary with no copying.  And I
seriously doubt there is a compiler in existence today that can elide
that copy, because of the restrictions on where the object must be
stored.

> If the function does return a reference, then simply store that
> instead of copying the whole object.

Yes, but now you have to tell the user "don't call me with anything
that returns a temporary, even though I'll compile it without
complaint."

        f_er f;
        f.set_table(create_a_table()); // whoops, the table disappears
        f.f()                          // BOOM

or whatever.

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

riiiiiiight.....

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

...but that's not holding it inside a boost::function<>.  The whole
point of function<> is type erasure, and with it goes the information
about how to process named parameters.

This doesn't seem like a very well-reasoned argument you're making.

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

Oh, that's simple.  There aren't any alternative libraries for this
task "out there."

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

And my point all along is that you can do that but you need to tell
users to be careful with temporaries in that case.

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

Fair enough.  You're entitled to it.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com