From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-07 15:03:21
----- Original Message -----
From: "Ullrich Koethe" <koethe_at_[hidden]>
> I strongly agree that this is a very important extension. Here is an
> example that might be a little easier to explain:
> Given two modules:
> - uimodule.so: contains wrapped C++ user interface widgets
> including, say, "Window"
> - logicmodule.so: contains application logic and a new widget
> derived from "Window"
> Now the problem is: how can we use "ResultsWindow" like any window
> defined in the UI module, *without* merging the two modules into one?
This addresses what Prabhu is doing, but I think it leaves the OP (Ralf) out
in the cold. He's not interested in cross-module derivation AFAICT. He wants
the from_python/to_python functionality from one module to be available in
another, so that module A can use module B's wrapped types as parameters and
> I think it can already be done with BPL. (At least, the following worked
> in my tests.)
> 1. wrap the UI classes into uimodule.cpp as usual.
> 2. in uimodule.cpp: define functions to retrieve the class object for
> any class needed in another module:
> boost::python::detail::extension_class<Window> * get_window_class()
> dynamic_cast<boost::python::detail::extension_class<Window> *>
Why do you need the downcast here?
> Declare these functions in a header "uicommon.hpp"
> 3. Wrap the application logic and "ResultWindow" into logicmodule.cpp
> as usual:
> reswindow_class(logicmodule, "ResultWindow");
> 4. in logicmodule.cpp:
> - Include "uicommon.hpp"
> - declare the wrapped "Window" as base of the wrapped
I think I see a way to do this without the get_window_class() function. I
think it also will substantially cut down on code bloat. The usage would be
We could provide some nice wrapper functions to insulate users from the
direct Python API stuff above. Hint: class_registry doesn't really need to
> 5. *Dynamically* link logicmodule.so against uimodule.so
> g++ -shared -o logicmodule.so logicmodule.o uimodule.so \
> 6. Then in Python
> >>> import ui
> >>> import logic
> >>> result_window = logic.ResultWindow()
> >>> ui.show(result_window)
> Function show() from module ui can be applied to an object from module
> [Note: to make this work, line 33 in module_builder.cpp must be
> commented out:
> // assert(name_holder.get() == 0);
Why? Have you got the latest module_builder.cpp with the destructor
> David, is there anything inherently wrong with this? It certainly works
> in a simple test setting.
Mostly it looks terriffic, though I'd like to see it substantially
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk