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

Daniel Wallin <[email protected]> writes:

> David Abrahams wrote:
>> Daniel Wallin <[email protected]> writes:
>> 
>>>David Abrahams wrote:
>>>
>>>
>>>>Daniel Wallin <[email protected]> writes:
>>>
>>>Are you not implying that we wouldn't have any chaining at all? Or at
>>>least only one step of chaining?
>> Yes, one incoming argument package for each CallPolicy in the
>> sequence.  But let me be clear, although those CallPolicies in the
>> sequence are conceptually all siblings in my proposed arrangement, it
>> is possible to generate a parent-child relationship as well, by
>> wrapping that sequence in another CallPolicy which preprocesses the
>> argument_package.
>
> OK.
>
>>>I find this hard to explain well. Does it make any sense?
>> I think I understand it, but I think it's too difficult.  IMO we
>> need
>> to come up with something that's conceptually easier to manage.
>> Let's take a step back and look at the DSL for specifying policies.
>> First of all, we need to decide whether "_1" refers to C++ arguments
>> or Python/Lua arguments, or both.
>
> My view is that "_1" refers to the C++ argument, and argument_package is
> responsible for mapping C++ argument positions to Lua/Python actual
> arguments.
>
>> I would be strongly inclined to say that unless you _explicitly_ say
>> otherwise, each C++ argument comes from the Py/Lu argument in the
>> same position.  Your example uses implicit argument shifting, which
>> makes me  nervous.  
>
> Why does it make you nervous? Is there any potential danger in doing
> this that I'm missing?

Well, suppose in a 5-arg function you write:

      getC++.arg(2).from_Python_arg(1)

[Sorry, can't stop inventing syntax ;-)]

The question is, what happens to to the other 4 arguments?  It's far
from obvious to me.  Now suppose you add

      , getC++.arg(1).from_Python_arg(4)

Now it's even less obvious.

>>       _1 <- _1+_2,  _2 <- _3, etc
>>     ;-)
>
> I don't know.. I don't like being forced to be explicit about things
> when they could just as well be implicit with no risk of ambiguities or
> mix-up's.
>
> And well, ... the syntax is insane. :)

I think it's beautiful :)

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



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/