GObject adaptor comments (GEP 5).

[Michael Meeks <michael ximian com>]

Hi Mark,

	Ok, so since it seems there's a likihood that we'll still use this,
despite my increasing confusion as to where it fits into a coherent
platform / API strategy, I've poked at the code a bit. As you may
imagine I have some questions / points, of varying detail:

	a) Given that the GOA is single inherited - it is pretty much a
pre-requisite (for me) to have nice stubs that could do this:

void Foo_doBaa (My_Foobar *foobar, int i, CORBA_Environment *ev)
{
	if (foobar->isLocalAndRightType)
		foobar->servant->klass->[something]doBaa (
			FOO_BAR (foobar->servant), i, ev);
}

	ie. almost no pointer dereferences, and a GObject type check. I can't
see how you can possibly achieve this, given that you copy the methods
from the generated IDL into the class structure, and thus add potential
order / fragmentation confusion.

	Now - you may argue that you can do this already _But_ you cannot
unless you inherit from an existing object; thus this is going to lead
to a culture of unneccessary sub-classing, creating an unneccessary tie
between implementation and interface.

	b) Why do we bother adding each method individually, when we can have
the type information for the entire block of methods provided by the IDL
compiled headers we have to include anyway.

	c) Why do we do this in a type unsafe way by having this vague
ORBit_gmethod_register, instead of the more strongly typed BonoboObject
POA__epv population method ?

	d) Why do we 'cut and paste' information unnecessarily, such as all the
method signatures twice, once in the header, once in the file
class_init.

	e) Why do we not virtualise the invocation mechansim on orbit-gservant,
so that we can provide (if we wish) a much faster switch based
implementation of method lookup; perhaps splitting out method lookup
would be best.

	f) The gorbit method search looks quite interesting nonetheless.

	So; at that point I gave up ;-)

	In conclusion, the epv re-orderability, and the fact that you have to
do all this heavy duty 'GSignal' like typing makes me unhappy with the
whole scheme. I think an approach more similar to BonoboObject would be
simpler, _and_ type safe, robust over IDL changes etc. So, I'm now less
opposed to this in principle, but more in practice so ...

	Making things like GSignal is no advantage; fixing GSignal so it works
more pleasantly would be better ;-) Indeed, having IDL generated signal
stuff for gtk+ would be rather nice in an ideal world IMHO.

	HTH,

		Michael.

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