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

David Abrahams wrote:
> Daniel Wallin <[email protected]> writes:
 >
>>So in this case, nothing would happen to the other arguments. I'm
>>missing what's not obvious here, sorry. What I considered before was
>>just converters that could merge several (consecutive) Python/Lua
>>arguments into one C++ argument,
> 
> 
> Oh, that's a restriction you hadn't explained.  They only _merge
> consecutive_ args!  That might be reasonable.

Yeah that means we wouldn't need to mess around with the Python/Lua
index, since it would be implicit. I'm not sure it's good enough though, 
perhaps we'd need to index Lua/Python args as well..

> Nesting of policies, however, would only work if they were properly
> sorted.  I think some other mechanism is needed for the siblings to
> communicate positional information up to a parent policy.

At least if the operations isn't commutative with respect to nesting
order. Any ideas?

>>in which case implicit shifting would be great. 
> 
> 
> Yeah.  Ironically (?), I think needing to explode a single Python
> argument to two C++ args is far more likely:
> 
>     void f(int count, char const** strings);
> 
>     >>> f(['foo', 'bar', 'baz'])

OK, so that implies that we need to be able to index Python args as
well, no?

   def(&f
     , array_with_size::ptr(_1, _1)
                        C++ ^^  ^^ Lua/Python
     , array_with_size::size(_2, _1)
                         C++ ^^  ^^ Lua/Python
   );

or something..

> Did you happen to notice the discussion of runtime-polymorphic,
> unified-syntax wrapping on the C++-sig?

Yes I did but I'm not sure I like the idea. For instance, it means
policies would have to be completely language-independent which I don't
think is always possible. It would be nice to have the same interface
though..

   void wrap_my_functions(boost::language_backend& backend)
   {
      module("baz", backend)
      [
         class_<bar>("bar")
            .def("f", &bar::f)
      ];
   }

But anyway, we would need to sacrifice a lot of compile time
possibilities to get there, wouldn't we?

-- 
Daniel Wallin



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