Re: New 'GObject' as base for GtkObject?

[Karl Nelson <kenelson ece ucdavis edu>]

> > - abstract callbacks in some way. A callback is not necessarily a
> >   function pointer.
> >
> 
> This is a good idea, complicated because you also have to abstract
> marshallers. Has any discussion gone in to how to do this?
> 
> What about a signal-signature->marshaller lookup table used to find
> alternate marshallers.  Then an additional flag passed to
> gtk_signal_connect_still_more_full() that specifies which marshaller
> set to use. So default handlers and connections done with
> gtk_signal_connect() use the default marshaller still. C++ bindings
> could pass an instance/memberfunction pair instead of a GtkSignalFunc
> to connect_still_more_full(), and then provide marshallers that 
> invoked the instance/memberfunction pair.

I have discussed a number of ideas with developers on the gtk+ irc.
Things like separating the marshaller from the argument launcher
have also been discussed.  In Libsigc++, the marshaller is a
function that takes the new return value and old one
and combines them together, returning a code on whether to
continue the emission or not.  This would avoid a lot of calls 
to the emission stop.  (The launcher is the slot
that processes the arguments from a list to a function call again.) 
If you eleminate the global lists from the emission process the 
system would be thread safe without needs for a global lock 
like gtk+.  However, the conclusion always seems to be "it would 
have been nice, but it is too late now."

I personally think that it would be great if the object system
and signal system got a good long design review, but I don't think
that is possible as no one would ever agree.  

However, I think this discussion is premature (or grossly too
late,)  splitting and redesigning the object system from gtk+
is really material for 2.0 of the library.  In order for
it to be usable to the wrappers and ensure flexiblity, we
can't just say here is code and use, so elegance of
design has to be made.  Otherwise you end up in the same situation
as today.

For example,  from the C++ prospective (these cover all of gtk+
and some reflect on the object system)

- you can't use static cast at all in C++ because the gtk+ object
  model has no concept of casting to primitive object and use
  its functions.
- The type argument interface is almost worthless as it does
  not have any way of typesafety, nor can it be easily cast as
  a stream.  (args interface should take float, int, or strings
  and handle them all instead of casting to what is exected and
  barfing!)   In otherwords be typesafe and if you can't be
  able to take all inputs and deal with them safely. 
- there is not way to make a looks/works like something that
  isn't exactly that type.  (poor abstractions)  (Okay this
  is my glist beef and I will carry to my grave.)
- Too many damn fragments which all have their own reference
  interface.  Why can't they all come from a very simple light
  interface.
- lack of multiple inheritence.  Really it is much more OO to
  define an interface (which may have some data like a signal)
  and then have every thing that has that interface inherite from
  it.
- provide hooks to wrappers (meaning the wrappers need to be 
  thought out in advance.)  We don't want to have all the overhead of
  checking and dynamic gtk+ casting all the time because we are a
  strongly typed language and thus we can give you the exact type needed.

I could go on, but I would simply be ignored.
  
> I'm sure that won't work but I don't see why just now. ;-)

--Karl