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

David Abrahams wrote:

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

Looking back, I really don't understand:

http://article.gmane.org/gmane.comp.lib.boost.langbinding/253

Looks fine to me.

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

Hm, I might have misunderstood. My interpretation was that we would
somehow produce one argument_package for each CallPolicy in the
sequence, starting from the native package. Looking back, that's how I
interpret it now as well..

Are you not implying that we wouldn't have any chaining at all? Or at
least only one step of chaining?



I've been thinking about this some more. Maybe argument_package just
isn't enough. I think we need a way for the converter to filter the
argument's passed to all trailing converters. Consider a converter which 
operates on 2 lua/python arguments and produces one C++ argument. We
could have something like:

   void f(int a, int b);
   def(&f, add_policy(_1, _2));

   :: f(1, 2, 3) -> f(3, 3)

The invoke-code would look something like:

   f(
       converters.convert(args, mpl::int_<0>())
     , converters.convert(args, mpl::int_<1>())
   );

But when the second converter asks the argument_package for index 1 it
should get index 2 because the first converter skips one index. This
won't work with the simple argument_package idea since the operation is
dependent on the order in which the package is composed. Also the first
converter will ask the package for index 1 as well, and expects to get
the unfiltered index..

argument_package's can only handle operations which are commutative with
respect to composition order. For instance, offset every argument N
steps or switch positions for some arguments.

So what I'm saying is that we might need two different concepts here.
ArgumentPackage, which is global for all index operations. And
IndexFilter (or something with a better name) which is connected to a
single converter, and is applied to all trailing converters.

We would end up with something similar to:

   native_pkg args;

   f(
       cv0(args, 0)
     , cv1(cv0.index_filter(args), 1)
     , cv2(cv0.index_filter(cv1.index_filter(args)), 2)
   );

I find this hard to explain well. Does it make any sense?

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