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

Daniel Wallin <[email protected]> writes:

>>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". 

No, I'm sorry.  From a conceptual POV, a
return_internal_reference<1,with_custodian_and_ward<2,3> > is a single
CallPolicies object with no "parent".  There are rules for how each of
these _templates_ composes with other CallPolicies types, but once
you've built the type you're dealing with a single thing.

> This is something I'd like to avoid since it complicates the concept
> for policies a lot.

Just call your thing something else.  ArgumentPolicies?  I don't care.
There's no reason inheritance has to be used for composition.  I don't
even like it all that much, but it has distinct advantages in terms of
the EBO.  

Regardless, to produce any single entity (type, object, etc.) which is
shared by all arguments, you're going to need some protocol which
determines how it's composed.  Each ArgumentPolicy needs to get a
crack at modifying the type somehow.  As I've been saying, *I want to
deal with those issues at a different level of abstraction*.  We don't
need to think about it at the level of function invocation; we can
just assume that the ArgumentPackage type has been constructed at that
point.  It's the issues of how composition works that complicates
things, so let's not make it an issue for CallPolicies, OK?

>> >> >    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.

There is no agreement that the CallPolicies is a tuple or any other
particular structure, as far as I'm concerned.  All we've said is
that you have to be able to get a tuple of converters, an argument
package type, and per-call state (probably part of the argument
package) from it.

> 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.

Actually, it does matter.  Remember that invocation functions will be
overloaded on arity, so the less code written in each one, the less
it will stress the compiler.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



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