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

At 14:52 2003-09-21, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> >> >>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?
>
>I don't know, maybe I misinterpreted you.  I don't see why/how it
>would affect the CallPolicy concept.  Right now in Boost.Python
>there's nothing in the concept which says "you must use
>inheritance".  It's just that since it's a multidimensional thing
>(result converter, argument package, precall, postcall) it's very
>convenient to use inheritance for composition and overriding a single
>dimension.

Right, but there is something that says every policy has to be aware
of it's "parent". This is something I'd like to avoid since it complicates
the concept for policies a lot.

> >> >    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;
>
>You're still using your per-argument CallPolicy concept.  I thought
>we agreed that CallPolicies was a single wad that gets passed into
>the invoke function.  Maybe the problem is that I never got you to
>agree to that.

Actually I wasn't. call_policyN was just the N'th element of the call policy
tuple. It wasn't related to arguments.

Anyway, it doesn't really matter if the CallPolicies type is built in the 
invocation
function or elsewhere. Since you seem to prefer elsewhere, I suggest we
go for that.

>Using the decomposition of functionality I outlined a few posts back,
>there's no need for multiple per-argument policy types at the point of
>function invocation.  The world is already complicated enough right
>there; we should be dealing with a few larger-scale types at that
>point in the code.  You can build the big CallPolicies wad any way
>you like (including by composing argument policies) but I don't want
>to force that particular structure on wrapped function invocation.
>It may not always be the best choice.

Right.

> >>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.
>
>Yes, done elsewhere please!

Ok.

> >> >    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.
>
>Those may not be too serious, but they are worth considering.

Agreed.

---
Daniel Wallin



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