Re: Re: [C++-sig] [Implementation] Calling wrapped functions, converters, policies

At 03:58 2003-09-21, David Abrahams wrote:
>David Abrahams <[email protected]> writes:
>
> > I'd like to see a templated protocol to access the actual
> > argument list, e.g.:
> >
> >      get<1>(args)  ->  "argument 1"
> >
> > we'd define a get<> which operates on PyObject* (argument tuples) but
> > we could also wrap the argument tuple in a kind of mapping to drop the
> > first argument (or inject a faux argument, in the case of an out
> > parameter which doesn't actually appear in the incoming argument
> > list).  For handling lone conversions (like extract<T>(obj)) we could
> > wrap a single PyObject* (argument) in a class for which only get<0>(x)
> > (but not get<1>, get<2>,...) was defined.
>
>Still another possibility is to tie the interface into the
>CallPolicies, which would eliminate some questions about where users
>who define new policies customize (and would let constructor_policy
>continue to use PyObject* as an argument_package, but then requires
>the CallPolicies to be passed to the converters (ugly).

Hm.. I don't think I understand why the converters would need CallPolicies.

>Still another
>possibility is to require a class type with member get/arity for
>argument_package.
>
>Thoughts?

Yeah, it looks good. I guess we would need to complicate things a bit though,
since we don't have inheritance from our base policy:

   struct CallPolicy
   {
      template<class Base>
      struct argument_package
      {
        typedef /* .. */ type; // perhaps this doesn't need to be a 
metafunction..
      };
   };

   typedef typename LanguageDescriptor::argument_package arg_pk0;
   typedef typename call_policy0::template argument_package<arg_pk0>::type 
arg_pkg1;
   typedef typename call_policy1::template argument_package<arg_pk1>::type 
arg_pkg2;

   arg_pk2 argument_package(arg_pk1(args_));

   f( c0.convert( argument_package.get(mpl::int_<1>()) ));

Also keeping the get() function in the argument_package type seems simpler 
to me.
We would probably need to wrap your PyObject* args in a class type anyway, so
that we can have a single access point to args/self/result.

---
Daniel Wallin



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf