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

Daniel Wallin <[email protected]> writes:

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

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.

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

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

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