Re: GObject adaptor comments (GEP 5).

[Mark McLoughlin <mark skynet ie>]

Hi Michael,
	You'll note, of course, that I did say that this was a
'prototype' implementation - and the thing that bothers you most here
was the one thing I thought most likely to change.

On 30 Sep 2002, Michael Meeks wrote:

> 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.

	Well, the stubs could be faster than they currently are in the
in-proc case, but no - as the method registration is currently done it
could never be as fast as what you outline above.

	But, I don't understand why such fast stubs are a
'pre-requisite'. Even as the stubs currently stand they would be a lot
faster than signal emissions - so given that there are a lot less
in-proc method invocations in your average GNOME app than there are
signal emissions I don't see how slightly slower in-proc invocations
would be such a bottleneck ....

> 	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.

	b), c) and d) are all to allow the potential order /
fragmentation confusion you talk about (I call it flexibility). But
sure, its debatable whether it is of any use.

> 	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.

	Why would we make it optional? Why not decide on whether we'll
go for the switch-based lookup rather than the generic lookup. I went
for the generic lookup in the prototype so as to further reduce the
amount of code in the skels, but its likely that its not a huge win.

> 	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 ...

	Of course all this input is all very nice and useful and I'm
glad someone else is looking at the code etc. ... but we're still on
the requirements GEP which ends Saturday and I haven't heard much
discussion of the actual requirements I have in the GEP. Any thoughts
there?

> 	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.

	Oh, you'll like gob then ... :-)

Good Luck,
Mark.