Re: [Implementation] Calling wrapped functions, converters, policies

Daniel Wallin <[email protected]> writes:

>>>>>Meaning we would need to make the
>>>>>nested argument_package a metafunction:
>>>>>
>>>>>  struct my_policy
>>>>>  {
>>>>>      template<class Base>
>>>>>      struct argument_package
>>>>>      {
>>>>>          typedef offset_arg<1, Base> type;
>>>>>      };
>>>>>  };
>>>>
>>>>That might be better.
>>>
>>>I disagree. Earlier I agreed with you that it was better to consider
>>>CallPolicies as one concept and doing the actual composing (?) at
>>>another level. To me, having a metafunction implies that there are
>>>actually other CallPolicies as well. Which seems to contradict our
>>>there-is-only-one design somewhat.
>>
>> OK, I understand, though I think I disagree.  It only implies that
>> CallPolicies don't have a fixed notion of what kind of argument
>> package they're going to get.  That's a separate issue.
>
> Yeah, you are right. I agree. The default_call_policies would be
> completetly unaware of it's language context, it's argument_package
> would just be the identity function. 

??? how is an arguemnt package a function???

It's data plus get and size/arity functions

> That also implies that default_call_policies might be usable for
> both lua and python without needing to be templated. Cool. :)
>
>> Let me try to further understand what's going on here.  When we
>> compose CallPolicies, do we want to transform the argument package
>> sequentially as it passes through all the sub-policies?  
>
> I think so.
>
>> If not, I presume this wouldn't be an issue.  What are the use cases
>> which lead us here?  
>
> The first use case was that you wanted your constructors to have their
> arguments offset, also you mentioned something about converters that
> operate on several arguments and.. And converters that doesn't operate
> on any arguments at all but produces a value from some other source.
>
>> The only one I can think of at the moment is the one which
>> repackages arguments to drop the self argument when building injected
>> constructors.  *That* sort of thing can be handled by wrapping a new
>> CallPolicies template around the composite, and having each element of
>> the composite do only its *own* transform on the incoming (native)
>> argument package.  In fact that seems much more appropriate to me in
>> many ways.  After all:

Just curious: what happened to the blank line that was here in my
original posting?

>>     policyA(_1) + policyB(_2) + policyC(_3)

likewise.

>> does little to suggest anything other than parallel operation.  If
>> we
>> were going to drop the first argument, I'd represent it using an
>> expression like:
>>     make_constructor_policy( policyA(_1) + policyB(_2) + policyC(_3)
>> )
>
> Wait, you are saying you would represent it like that *internally*,
> right? Not in the interface?

Well, both perhaps.

>> As a result, the CallPolicy generated by make_constructor_policy would
>> be something like:
>>     constructor_policy< composite_policy_generated_by_addition >
>
> OK, here only constructor_policy's argument_package would be used? No
> composition at all? 

No, each element of the composite would get a shot at modifying
(wrapping, really) the argument package, but each one would start with
the same argument package, the one supplied by constructor_policy,
rather than starting with one that had possibly been modified by all
previous policy elements of the composit.

>>>>Nasty.  Forwarding is hard to do well.
>>>
>>>Not in this case. Every argument_package must be constructible from the
>>>native argument package, so there is no forwarding problems here. Not
>>>that I can see anyway.
>>
>> Now I'm really confused.  What you're saying seems to imply that
>> there's no need to chain transformations of the argument package type.
>
> I don't know how it implies that. My point was that the generated type
> composite_argument_package<> just forwards the incoming PyObject* (or
> whatever native package type we have) to it's base. I guess I don't
> understand why there would be an issue with forwarding here.

Never mind; I was confusing compile-time/runtime functions.  I think
that's a first for me!

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



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl