Re: [Boost Python Library] Mixing types wrapped in different modules

From: Ullrich Koethe (koethe_at_[hidden])
Date: 2000-12-07 15:46:14

David Abrahams wrote:
> 
> ----- Original Message -----
> From: "Ullrich Koethe" <koethe_at_[hidden]>
> 
> >
> > 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
> return values.

Yes, but note that from_python/to_python only works if both modules use
the same extension_class instances - otherwise, Python would report
incompatible classes even when the wrapped C++ classes were identical.
So, I think we need common files for the shared stuff even if we don't
want to inherit. (For example, I also tested the case where
"logicmodule" added a function that takes a "Window" as an argument -
this function also accepted Windows created by constructors from
"uimodule" and a third module which also extended the ui module.)

> >     boost::python::detail::extension_class<Window> * get_window_class()
> >     {
> >       return
> >         dynamic_cast<boost::python::detail::extension_class<Window> *>
> >         (boost::python::detail::class_registry<Window>::class_object());
> >     }
> 
> Why do you need the downcast here?
> 

extension_class.declare_base() expects an extension_class, while
class_registry stores an extension_class_base.

> 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
> something like:
> 
> reswindow_class.declare_base(PyObject_Getattr(PyImport_GetModule("uimodule")
> , "Window")))
> 

This is very nice, and would also ensure that "uimodule" was imported
before "logicmodule". But again, a downcast is required.

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

Why not???

> >
> > [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
> ~module_builder?
> 

Maybe my sources are outdated. In the version I used, the assertion
ensures that only one module_builder is constructed in a module. But
after dynamic linking of "logicmodule.so" against "uimodule.so", there
are two module_builders in "logicmodule.so". This is not an error,
because uimodule's module_builder is not used in "logicmodule.so".

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

So do I. It was just a first shot to get us started. (To be honest, I
was very surprised that such a simple technique worked at all.)

Ulli

-- 
 ________________________________________________________________
|                                                                |
| Ullrich Koethe  Universität Hamburg / University of Hamburg    |
|                 FB Informatik / Dept. of Computer Science      |
|                 AB Kognitive Systeme / Cognitive Systems Group |
|                                                                |
| Phone: [phone]                Vogt-Koelln-Str. 30 |
| Fax:   [phone]                D - 22527 Hamburg   |
| Email: u.koethe_at_[hidden]               Germany             |
|        koethe_at_[hidden]                        |
| WWW:   http://kogs-www.informatik.uni-hamburg.de/~koethe/      |
|________________________________________________________________|