[boost] Re: [Review] Named parameters library

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-17 18:47:46

Matt Hurd <matt.hurd_at_[hidden]> writes:

>>David Abrahams <dave_at_[hidden]> wrote:
>> Daniel James <daniel_at_[hidden]> writes:
>> 
>> > Sorry, another feature request. Would it be possible/a good idea to
>> > add a way to get the type of a named parameter?
>> 
>> Certainly it's possible.  Not sure if it's a good idea.  Is there a
>> use case?  Some people are complaining that the library is already
>> heavy artillery where none is needed.
>
> A use case I have that I'm not sure how best to approach, but would
> find incredibly useful, with named_params is using a compile time
> policy to support switching between:
>   1.  direct function call 
>   2.  an indirection to the function call, such as the marshalling and
> transmission of the function parameters, including formal parameter
> names, to a target.
>
> To do this, named_params needs to support an interface for iterating
> over the parameters.  

Why iterating?

> Getting type info and formal parameter names may
> help some styles of indirection.  

"may help some styles...?"  Doesn't sound like a strong argument for
introducing a new feature, to me.

> For example, matching the type to a
> specific transport's marshalling routine for the same type.
>
> The goal is being able to re-architect applications by simply changing
> policies at key workflow points in an application.  Change from a
> function call, to a threaded work pool, to a call to a separate
> process, to a call to a separate machine via a udp/tcp or even tib rv.
>
> I see named_params as a key piece of the puzzle in enabling this.

I don't understand the relationship at all.  Why not just use an
explicitly-secified function template parameter?

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