Repercussions of libbonobo's BonoboObject epv management strategy

[Michael Meeks <michael ximian com>]

Hi Darin,

On Fri, 26 Oct 2001, Darin Adler wrote:
> The BonoboObject in the new libbonobo requires that the epv for the
> class be embedded in the class structure.

	Quite right.

> ... it means that the size of the epv will now be hardcoded into the
> class's subclassing interface.

	Yes.

	This is not however, without design.

> Specifically, if you were implementing a NautilusView in C, you were
> immune to changes in the CORBA NautilusView API. All your calls to
> and from CORBA went through libnautilus and the details of the CORBA
> API (number of calls, parameters, and such) didn't show through in
> the C interface at all.

	This is true if everyone uses the library - quite
right. However, there is nothing to prohibit libnautilus from
aggregating a new (perhaps private) interface to an object it
constructs, that can contain new methods.

	Or - alternatively, if you wish to hide the CORBA - implement
a GObject, have an associated private BonoboObject, provide C wrappers
for all the methods etc. etc. This of course sucks badly, but then
BonoboObject is designed to remove the need for all these wrapper
classes and the mess that often goes with them.

> If bonobo_type_unique took a pointer to the epv rather than an
> offset within the BonoboObject, we would still have the
> abstraction. The epv could be declared as a global object -- no need
> to allocate memory or initialize it -- just declare it with all the
> function pointers pre-initialized in there.

	Ok - this is one approach I considered. Let me tabulate some
of the reasons for my thinking, vs. your approach - which is the other
obvious one.

Current approach:

Pros:
	+ The GObject way - methods declared in the class section.

	+ The GObject way - inherited classes get copies of these
	  methods ( allowing CORBA implementation inheritance and
	  overloading )

	+ The future path of ORBit2 / Bonobo involves moving to a
	  flat vtable structure, (much like a GObject class),
	  which will allow a single pointer dereference to map to
	  an in-proc method impl. via. a macro.

	to which I might add:

	+ Backwards compatibile with BonoboXObject.

Cons:
	+ The GObject way - if you wish to add (virtual) methods to an
	  interface, you cannot without breaking inherited classes.


Alternative approach:

Pros:
	+ Can add methods to an interface with impunity, and
	  derived objects will still function correctly.

Cons:
	+ epvs not copied when inheriting from an object, thus
	  implementation inheritance more difficult.
		- this could be fixed by adding the size of the epv
		  to the type init, and an explicit copy on derive.
**	+ Adding methods causes SEGVs on in-proc components who
	  implement the interface themselves (ie. not via a library)
	  by de-referencing a garbage epv pointer.
	+ The future planned path militates against this approach.


> Anyway, I figure I probably noticed this too late -- after API
> freeze -- and you probably love the way you did it, even after
> hearing my concern.

	Heh :-) well - I'm not convinced I love the way I do it, and
I'm currently trying to think of ways to help you hit the (**) more
quickly.

> But I figured I ought to mention it rather than just staying quiet
> and cursing my keyboard.

	So the API freeze shouldn't be an issue (I hope), since we can
in fact provide both behaviors I suspect. Personaly I think the
current setup is sufficient, but we can add a bonobo_type_unique_darin
(or sim.) that uses a different code path to setup, copy and manage
the inherited classes epv's. This should not in fact be that difficult
- but I'm not particularly interested in doing the work.

	What do you say ?

	Regards,

		Michael.

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