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

David Abrahams wrote:

> Daniel Wallin <[email protected]> writes:
> 
>>>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???

Sorry, I meant *meta*-function.

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

I don't know, I might have snipped them by mistake. I snip blank lines
sometimes. I can stop if it matters. :)

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

OK.

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

Right, so basically the modifications could be in the converter
generated by the composites rather than in the policy? Still, I don't
think it's sufficient for the case when you want one converter to
operate on several arguments.

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

:)

-- 
Daniel Wallin



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