Re: New 'GObject' as base for GtkObject?

[Karl Nelson <kenelson ece ucdavis edu>]

David wrote:
> In the end, I think having the GTK_OBJECT()-style
> casts be equivalent to C-style casts but w/ additional
> checks is rather nice.

It also means there is no possibility the class to be described
in anything but a very strict SI tree.  This is fine for most
things, but I feel very bad for a widget set.  Therefore, a
system the can do both might be best.  Unfortunately, mixing
them would mean complexity.
 
 
> In a widget system, these costs might be bearable,
> but in a general purpose object system they are more
> questionable.

The problem is in the way that those casts are applied and not
in the actual cost.  The cost of looking up in the MI system
was exactly the same as in the current Gtk+ system.  The
problem is how the casts are applied...

I could write

   gtk_foo_func_a(GTK_FOO(w),1);
   gtk_foo_func_b(GTK_FOO(w));
   gtk_foo_func_c(GTK_FOO(w),"hello");

or I could write

   GtkFoo* w_foo=GTK_FOO(w);
   g_return_if_fail(w!=0);
   gtk_foo_func_a(w_foo,1)
   gtk_foo_func_b(w_foo)
   gtk_foo_func_c(w_foo,"hello")

Clearly the second is preferable regardless of whether the
cast does checking or MI.  
  

> For example, in my server I have some places I've
> replaced the expensive casts to the native casts b/c
> they are called very frequently (e.g. in the GSourceFuncs functions).

Then the proper solution (the one we use in Gtk--) is to cache
those conversions in the object type that uses them.      
 
> In the end, my experiences with MI have been so negative (each time
> I've gotten rid of it before finishing) that I have little
> interest in these benefits for these costs.

What context were you using them in?  If used to define
virtual interfaces that are then combined to form classes they
can be used to great elegance.  


> (Interfaces, on the other hand, don't require making the casts
> non-equivalent.)

Interfaces that can't contain data mean that you can't make
virtual interfaces.  At first this doesn't seem all that
bad after all who needs them.  However, here is a senerio 
so common in gtk+ that it needs to be addressed and I
feel can only be done so with real MI...

  An object passes part of itself with multiple interface.
  The function calls a signal in the object.
  The emit function references the "object" to prevent
    early deletion.  

Hold on!  What is the emit supposed to reference.  It needs
to reference the real reference in the base object, not the
one in the interface.  

This means either interfaces must hvae virtual functions to
look up the reference, or the interface must be able to cast
to the location of the real reference.  

You can try to kludge around this by having lots of cases in
the functions that deal with referencing, etc.  But this
is incredibly bad OO.

I could scrap the data moving an make a pure java
model where only the class is built in my system.  (I
have both the class and object constructed without 
inheritance.)  But this is far less flexible as interfaces
would then need to use set_data to add their extra stuff.
Thus the object would become very fragmented.  However,
if this is the only form accepted I will code an example of
it.

- --Karl