"Hurd, Matthew" <hurdm@sig.com> 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