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

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-07 19:54:53

----- Original Message -----
From: "Ullrich Koethe" <koethe_at_[hidden]>
> David Abrahams wrote:
> > > Note that we
> > > can't use extension_class directly because we don't know the
> > > held_instance type if callbacks are enabled.
> >
> > It took me a little while to figure out what you were saying, but now I
think I
> > understand. You need to know the held_instance type to do the
downcast/upcast
> > stuff.
> >
>
> Exactly. But meanwhile I realized, that it can be done simpler still.
> I've added the following to extension_class:
>
>     template <class S>
>     void declare_base(type<S>)
>     {
>         extension_class_base * base = class_registry<S>::class_object();
>
>         if(base == 0)
>             throw std::runtime_error("declare_base(type<S>): base
> undefined.");
>
>         base_class_info baseInfo(base,
>                             &define_conversion<S, T>::downcast_ptr);
>         class_registry<T>::register_base_class(baseInfo);
>         add_base(ref(as_object(base), ref::increment_count));
>
>         derived_class_info derivedInfo(this,
>                             &define_conversion<T, S>::upcast_ptr);
>         class_registry<S>::register_derived_class(derivedInfo);
>     }

This seems to contradict the assertion that we need to know the
held_instance type. Actually, I don't know what I was thinking when I wrote
that.

> and a corresponding forwarding function within class_builder. Now I can
> write:
>
>     reswindow_class.declare_base(boost::python::type<Window>());

Great! We should be able to set this up so you can write:
    reswindow_class.declare_base<Window>()

> If one also needs from_python/to_python() for Window, one has to
> instantiate python_extension_class_converters<Windows> by the usual
> means. It is probably good to do this in a header which is included by
> all modules that want to share this class.

Yep.

> > OK, we should definitely explore this for the release following the one
Beman is
> > going to do this weekend. We can begin (on a branch of course) as soon
as you
> > like.
> >
>
> I've checked above proposal into branch 'shared_modules'. Tests are in
> directory libs/python/shared_modules.

Wonderful! I'll have a look... but that's the wrong directory for the tests.
They should either go in libs/python/test or libs/python/example. The
problem with mistakenly added modules is that you have to ask the
SourceForge people to clean them up :-(.

> > > 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.
> >
> > That's definitely true of to_python. I'm not so sure about from_python.
Really,
> > that conversion depends on a successful dynamic_cast to the appropriate
> > instance_holder<T>*. My understanding of dynamic linking and how it
interacts
> > with the C++ runtime is pretty sketchy at best, but I think this just
means the
> > modules need to be dynamically linked with one another.
> >
>
> But from_python() must still be defined by instantiating
> python_extension_class_converters, which requires knowledge of the
> instance holder.

Sure, in the current architecture. We could make to_python() and
from_python() independent but I don't think it would buy much.

> This should be done in one place (e.g. in a header file
> shared by all modules.)

OK, yes.

> > Common source files? Common headers? Common objects? I'm a bit lost.
> >
>
> See above and libs/python/shared_modules/shared.hpp for an example.

OK, I'll have a look.

> > > 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".
> >
> > Probably the best solution would chain the name_holders into a stack, in
case a
> > module might be initialized during another module's initialization.
> >
>
> Sounds right to me. Can you add that?

Sure, it would be easy. But is it needed for anything we're currently doing?
If so, should I add it to an existing branch?