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

At 12:38 2003-09-21, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> > 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.
>
>1. I want the converters to have access to the entire argument
>    package, rather than being passed a single argument.
>
>2. If the method of getting argument #N from the package is tied to
>    the CallPolicies, e.g. via a member or static function, then
>    naturally you need an instance of the CallPolicies or at least its
>    type in the converters.
>
> >>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:
>
>One might ask "why not?"  After all, your slick interface doesn't
>preclude inheritance as an implementation detail.

It wouldn't be an implementation detail if it affects the policy concept 
though,
would it? Or did you mean something else?

> >
> >    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;
>
>Just require ArgumentPackage types to have templated constructors and
>you can avoid all this multi-step hoo-ha.  You can pass a
>LanguageDescriptor::argument_package straight through to the innermost
>member or base class.

Right. You are just referring to the construction of the object? We'd
still need the "multi-step hoo-ha" to compose the actual type.

> >    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.
>
>It has two negative implications:
>
>    1. I can't just pass around PyObject* in the usual case, which is
>       likely to be more efficient.  Few compilers still pass classes
>       in registers.

Right.

>    2. The syntax for invoking get becomes ugly:
>
>          args.template get<3>()
>
>       I don't care so much for myself, but writers of custom policies
>       will have to touch that syntax too.

Ok.

> > 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.
>
>Huh?  Single access point?

Yeah, I meant that I would like all language dependent arguments passed to
the invoke functions wrapped in the same object.

I believe in python you get more than one PyObject* to your callback, perhaps
the self argument or something like that? I can imagine a lot of languages do
something like this. In lua your PyObject* is represented by a (lua_State*, 
int)
pair.

---
Daniel Wallin



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