Re: Exposing C++ objects to Python at runtime

Jonathan Warrington <[email protected]> writes:

> David Abrahams wrote:
>> Boost.Python doesn't work that way (and thank goodness!), so if you
>> really are wedded to an interface like that one, I wish you good luck
>> in your travels.
>> I get the vague feeling that you're so used to working in a
>> particular way
>> that you're unable to see that Boost.Python would actually serve your
>> needs, though I could be wrong.
>> 
>
> I'm not sure if it's that I'm used to working a particular way, or not
> (been awhile since I've coded in c++).  I guess I'd come up with what
> I thought was a good idea for a plugable system where all that was
> required to change scripting languages was to change the call to
> CreateScriptEngine.  Also not needing the developers to know anything
> about the scripting language, and the scripting system didn't need to
> know anything about the other components being written.
>
> Maybe I haven't given Boost.Python a fair enough look, I'll try to
> look at it without my preconceived notions of what I want,
> tommorrow. Thanks for all your help.

I think, now that I understand what you're doing, that Boost.Python
won't do what you want.

Your idea is a good one, but interestingly, it appears to still be
intrusive.  Your classes may not need to know about Python or
Boost.Python, but they do (according to you) need to know about your
scripting system interface.  Boost.Python lets you wrap classes that
know nothing of scripting or Python.

The Boost.Python C++ wrapping interface doesn't, in principle, *need*
to know about Python - more could be done through runtime
polymorphism, to isolate the compilation of wrappers from specific
target languages, but it would be costly in the size and speed of
extension modules.

I think the only way this makes sense is if you need to link support
for multiple languages into the same library or application.  Even
then, I might be inclined to use a templated (compile-time
polymorphic) interface to generate relatively fast-and-small
wrappers.  It doesn't seem as though there's a lot to be gained by
having a single copy of the wrapping logic for a class, since it will
end up doing many, many dynamic dispatches.

The boost-langbinding project is trying to address the question of
how to unify the implementations and syntax of Boost.Python and
Luabind.  It would be very interesting to think about how a "write
the wrapping code once" system might come out of it.

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