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

Daniel Wallin <[email protected]> writes:

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

Here too?

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

It matters for readability, but it seems to have the flavor of
something your mailer is doing :(, since it happened several times in
this message.

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

Here again.

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

Here again.

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

Here <sigh>

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

No, that's not what I had in mind.  But I guess that can work.

> Still, I don't think it's sufficient for the case when you want one
> converter to operate on several arguments.

In other words, when one C++ argument comes from several Python/Lua
args?  Why not?

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

Sounds like you just did it, too!

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