[boost] Re: [named_params] timing trivia and some comments

From: David Abrahams (dave_at_[hidden])
Date: 2004-03-03 18:21:49

"Hurd, Matthew" <hurdm_at_[hidden]> writes:

>> I guess my first thought is: "Whaa???  What does any of the above have
>> to do with a named parameters library?"
>
> Pretty much nothing.  I just like the named_params style of interface
> and wanted to adopt the approach.
>
> I want to build a mechanism where it is easy to build an interface to a
> function / functor than can have a policy that allows it to be a normal
> function or something else such as a function in worker pool or a remote
> function.
>
> My desire is to make it easy to represent a function and keep this
> orthogonal to whether it remote, pooled or local via a policy.  

You're describing boost::function<...> now.

> For some of the mechanisms I actually would like names for the
> parameters to help fulfil a protocol requirement, thus the desire for
> introspection on the names and a look into your neat library.

So put a named-param front end on a boost::function (?)

>> I can begin to vaguely see a reason to slap a named parameters
>> interface on top of the whole thing, but it seems like you could do
>> that as an afterthought.  Am I missing something?  I must be.
>
> One extra note for you.  There was a couple of typos in the doc.  From
> memory, the order of the arity and the keywords in the macro are
> transposed in the documentation.  Also the docs still refer to
> params[name | default] rather than p[name|default].

Hmm... Daniel?
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com