Re: Replacing GTypeInterface instances.

[Havoc Pennington <hp redhat com>]

murrayc t-online de (Murray Cumming) writes:
> > IIRC the best solution that was reasonably transparent to C++ users
> > involved dynamically generating proxy classes for C++ classes based on
> > RTTI on the C++ class.
> 
> It would be nice to know why this might be necessary. I think that I can
> see a way to do it just by replacing the vfunc table (the
> GTypeInterface-derived struct instance) with our own.

You mean derive a proxy class, or poke in the existing class?

>  i.e. you keep a hash from list of interfaces
> > implemented to proxy class, and you yank the right proxy out of your
> > hash on object construction. Or something.
> 
> Which would also require replacement of the GTypeInterface instance.
> That's what I need to know how to do.

You just override the interface as you would in a subclass, right. I'm
not sure we currently have any examples...

> > You might be better off just requiring C++ users to put in some funky
> > boilerplate, instead of trying to do it magically.
> 
> I don't think that it will be possible to make a C++ class implement a
> C++/Glib interface just by inheritance. C++ coders will also need to
> call
> implements_interface(TreeModel::get_sometypething());
> in the constructors of their C++ interface-implementing classes.

That's what I mean by "funky boilerplate"

The proxy hash I was describing is an attempt to avoid the funky
boilerplate. If you feel OK requiring some boilerplate, there are many
ways to do it, I don't think there's any big issue.

Havoc