Re: New 'GObject' as base for GtkObject?

[Owen Taylor <otaylor redhat com>]

Karl Nelson <kenelson@ece.ucdavis.edu> writes:

> 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.
  
Complexity? Well, a little, but not a whole lot if you
don't require inheritance of implementation. Certainly
nothing as complex as C++ is needed.
  
[...]

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

What is a virtual interface? (Isn't there some other
term than 'virtual' that people could use occasionally?) 

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

These presupposes that interfaces transparently look like
objects in C, which is certainly not necessarily the case.
The design that we've played around with (I always forget
the details, so Tim will have to jump in and correct me
is that an interface is just an extra vtable attached
to the object.).

Say we have the GtkRadio interface - an interface used
between a GtkRadioGroup object and a GtkRadio[Menu]Item,
and it has the "set_active" and "get_active" methods.

The implementation of gtk_radio_set_active() might
look like:

void
gtk_radio_set_active (GtkObject *object, gboolean active)
{
  g_return_if_fail (GTK_HAS_RADIO (object));
  
  GTK_GET_RADIO(object)->set_active (object, active);
}

With this scheme the original object pointer is always
passed around, and there is no trouble referencing
the object or emitting signals.

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

You seem to see multiple interfaces in terms of aggregation of
distinct objects, which is I think, a really kludgy wayof implementing
things.

Of course multiple interfaces are a powerful tool for enabling
aggregates while maintaining implementation independence (E.g, the
GtkRadioGroup / GtkRadioMenuItem aggregate mentioned akbove) but I
don't see such natural aggregates inducing hacks of the type you
mention.

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

A model that separates out interfaces from objects
instead of trying to make them appear the same makes
it pretty easy to make a much simpler implementation
that actually is compatible with existing GTK+
code since you don't have to solve the arbitrary
"cast object of type A to object of type B allowing
for multiple inheritance" problem.  

> But this is far less flexible as interfaces
> would then need to use set_data to add their extra stuff.

What extra stuff? Each class implementing an interface
is responsible for storing the data associated with
the implementation. The only functions that can be
generic to all implementations of the interface should
just be wrappers around the functions in the interface.

Regards,
                                        Owen