Re: GObject adaptor comments (GEP 5).

[Michael Meeks <michael ximian com>]

Hi Mark,

On Thu, 2002-10-03 at 04:33, Mark McLoughlin wrote:
> 	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.

	:-) Good oh'

> 	But, I don't understand why such fast stubs are a
> 'pre-requisite'.

	Well - the idea is that since it's so easy to do - and since we've
sacrificed MI, there's little point in not doing it :-) also, a simple
fn. pointer deref in the stub makes life far more debuggable, and the
stack frames far shorter, quite apart from the speed and complexity
wins.

	In my ideal world; we would do things differently, such that the 'stub'
if indeed we had one was merely:

	object_get_class (obj)->do_method (obj, a, b, c, ev);

	And that in the remote case, we would populate the vtable with
'stub-like' methods, that would do the bridging to the common ABI ->
marshalling for us.

	Thus in theory; if we had only in-proc objects, we would have a net
run-time cost of ~nothing :-) indeed, if we were facist memory
conservationists - we could save loading big chunks of the ORB / stubs
until such a time as they were needed for remoting :-)

	Certainly, that's the direction I'd like to be moving in. So, I suppose
that boils down to a requirement that:

	* In-proc method invocation should be as light-weight as 
	  possible in terms both of required infrastructure and
	  performance.

>  Even as the stubs currently stand they would be a lot
> faster than signal emissions

	Sure ;-) but who is happy about the signal emission overhead; also, I'd
like the technology to have the potential to be ubiquitous, so pruning
every available overhead is great.

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

	Fair enough; going with your tree thing alone is fine for me, as long
as it's not on the common in-proc path; indeed, I'd far prefer it to the
hefty, cumbersome generated skel switch stuff.

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

	Ah; ok - I have another one then:

	* Strong typing - the solution should endeavour not to sacrifice
	  the considerable strong typing possibilities facilitated by 
	  the necessary IDL compilation.

	Which just about covers it really. How about that ?

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

	Haha :-) but really, I'm talking about a more pleasant and generic and
re-usable, and accurate setup than gmarshal.list, and hundreds of lines
of dodgy, type-unsafe:

  widget_signals[SHOW] =
    gtk_signal_new ("show",
		    GTK_RUN_FIRST,
		    GTK_CLASS_TYPE (object_class),
		    GTK_SIGNAL_OFFSET (GtkWidgetClass, show),
		    _gtk_marshal_VOID__VOID,
		    GTK_TYPE_NONE, 0);

	etc. which I think can only be a positive direction.

	Anyway, with those 2 added requirements; I'm happy with the
requirements I think,

	How's that ?

	Regards,

		Michael.

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