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

David Abrahams wrote:
> Daniel Wallin <[email protected]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>>Daniel Wallin <[email protected]> writes:
>>>
>>Yes. It could be written:
>>
>>
>>Althought that's probably more characters to type. ;)
> 
> 
> Yes, and it feels wrong to have to know about composite_package at the
> level of implementing get for offset_arg.  But worse, what *is*
> offset_arg in this case, anyway?  It can't be an argument package,
> because it doesn't stand on its own - you can't use it without a
> native argument package.  It could be an "argument repackager".

Yeah, you're right. It's basically just a tag type used to dispatch to
the correct get() function. I think I could agree to having a
metafunction that generates the argument_package type..

>>>>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. 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:
> 
>     policyA(_1) + policyB(_2) + policyC(_3)
> 
> 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?

> 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? I don't think that's sufficient to cover all use
cases, we'd need to compose the package from the entire CallPolicies
sequence.

> Am I making sense to you?

Yes.

> Then I'm also asking myself whether these policies need to explicitly
> declare their argument package transformations, or whether we can get
> away with a chain of calls:
> 
>     p3.repackage(p2.repackage(p1.repackage(native)))
> 
> I think this might be hard to achieve without auto/typeof/decltype.

Right. At least if we don't want that expression in the convert() calls.
Which I'm sure we don't.

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

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