Re: bonobo and interface inheritance issue

[Michael Meeks <michael ximian com>]

Hi Bill,

On Wed, 20 Jun 2001, Bill Haneman wrote:
> It seems to me that the only way for bonobo components (at least those
> based on bonobo-object.c) to implement an IDL interface that is a
> subclass of another is if the implementing bonobo object is itself
> inherited from a bonobo object which implements the parent class: thus

	This is the case with BonoboObject / BonoboXObject. ie. if you
have:

	interface A : Bonobo::Unknown;
	interface B : A;

	You can't easily implement B without creating a thin / empty 'A'
GObject - this is because this is not a commonly needed feature, and thus
to simplify bonobo_type_unique I made it like that.

	It is easy to fix ( perhaps ), with a bonobo_type_unique_multi or
somesuch, that passes in several epv pointers / offsets for one layer of
GObject implementation inheritance.

> Now, since CORBA is just about interfaces, a CORBA object doesn't
> inherit any implementation.  But it seems in bonobo that
> implementations *are* inherited

	Ultimately of course you need to inherit the Bonobo::Unknown
implementation or your aggregation and ref counting breaks.

>, and in fact since GObject does not (yet??) support overriding of fps in
> the vtable, the result seems to be that the inherited implementations
> (from the bonobo parent class) are not overridable.

	When you sub-class the parent 'Class' structures are copied into a
new class structure copy for that sub-class, so that you can modify the
function pointers in there with impunity. ie.

	In class init:

		my_class->parent_class.destroy = my_destroy_handler;

	( for a prevalant example ).

> My initial impression is that the epvs for parent classes (in the
> class struct) are shared with the parent type, thus not overridable.  
> It secondly seems that only the new methods (those not in the parent
> IDL) can be specified in the bonobo class init func, the parent IDLs
> implementations seem to require that a bonobo parent class exist which
> fills in the appropriate epv.

	Um, perhaps this is an artifact of the artifice of setting up a
local 'epv' pointer to fill in the epv, of course you can fill in your
parent epv as well.

> however it seems that RegistryClass cannot specify the notifyEvent
> method since it's in the parent interface's epv

	Just overwrite it.

> furthermore if RegistryClass inherits from ListenerClass it will have
> a notifyEvent method pointer but there appears to be no way to
> override that method.

	Poke at it with a poker directly :-) it seems savage, but it's the
Gtk way...

	HTH,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot