Re: mango ideas..

[Mathieu Lacage <mathieu eazel com>]

hi Robert,

comments below.

Robert Wittams <robert wittams ic ac uk> writes:

> 
> I was wondering if this might be an interesting thing
> to do (perhaps later)..
> Most people (ie newbie GTK programmers included) are very comfortable 
> with connecting callbacks to signals of existing objects. 
> Eg clicked signal of button. 
> 
> Moving onto deriving their own GTK objects is often a big step due to
> the necessary complexity of the g[tk]object system. 
> So I was thinking, if we want a lot of people (including newbies) to 
> be implementing servers, the following might be a way to acheive this.
>  
> Make your skeleton generator generate for any particular interface 
> a complete implementation of an object. This includes all gobject 
> house keeping code. It should also for each corba function in this 
> interfaces inheritance tree define a signal and a virtual function. 
> The virtual function should merely emit the signal, and deal with 
> return / out values. 
> 
> So then it should be possible to merely instantiate this object 
> and connect simple callback functions to it to make a quick and 
> easy implementation of a CORBA server.... 
> 
> Hope this makes sense and I haven't missed anything... 


It does make perfect sense:
as a matter of fact, one of my own personal views of this mapping was 
to make it natively emit signals because it is so easier to use
it that way.

Maciej convinced me not to do this for now and not to specify it in
the mapping because of the necessary overhead it involves: the signal 
system has a certgain overhead associated with it.

One thing for sure is that we can do as you suggested and try it that
way later :)


I must say I do not really fee l concerned by efficiency unless
it is a major problem which it is not in this case (the overhead could
not be really so big).

So, we will see.

thanks a lot for your feedback!

Mathieu

-- 
Mathieu Lacage <mathieu eazel com>