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

David Abrahams wrote:
> Daniel Wallin <[email protected]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>>Daniel Wallin <[email protected]> writes:
>>
>>
>>>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..
> 
> 
> I prefer:  array_with_size(_1, _2) <- _1
> 
> without the arrows it gets really hard to keep track of all the
> placeholders and what their roles are.

OK. :)

>>>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. 
> 
> 
> I recognize that problem, but I think we ought to give it more
> thought.  I'm not sure it's precisely accurate.  I can imagine a
> plug-in system which allows users to add language-specific
> policies... but my primary interest in it has to do with reducing
> compilation time.  Assembling the converter lookup logic (etc.) just
> once instead of multiple times could be a huge benefit.

My primary interest in it would be the language-independent interface,
adding support for multiple scripting languages with the same calls
would be great. I'd hate to give up on compile time knowledge by
introducing a virtual call boundary though, so lets think about this
some more.

>>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)
>>      ];
>>   }
> 
> 
> Yep.
> 
> 
>>But anyway, we would need to sacrifice a lot of compile time
>>possibilities to get there, wouldn't we?
> 
> 
> I'm not convinced we would.  Let's keep it in mind as we go forward.

Agreed.

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