Re: [boost] Re: [Review] Named parameters library

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-11-17 22:07:20

>David Abrahams <dave_at_[hidden]> wrote:
> 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?

I would like to have a generic way of  injecting before a function
call a call to marshalling code for a suitable transport.  For some
transports/protocols, such as tibco's rendezvous, having parameter
names in addition to the data and any index is preferred.

I was thinking that being able to interpose a policy that would
interate over the parameters to the fn call and package them for
transport to the policies destination would  win most of the battle. 
Something along the lines of a functor that used named_params and some
policies that would inject marshalling / sending to target, and,
receiving  / unmarshalling code.

A null marshalling policy just calls the function without doing
anything.  A thread_pool marshalling policy might queue param info
onto the work queue.  A tibco rendezvous policy would include the
formal argument names along with the parameter data..., etc...

matt.