Re: New 'GObject' as base for GtkObject?

[Karl Nelson <kenelson ece ucdavis edu>]

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

Well, gos was dead simple.  The complaint about multiple inheritance
is that the table are horrible.  Mixing gtk+ like SI with 
gos MI and expecting the class builder to work would make a
mess out of the simple tables.

>   
> [...]
> 
> > > (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?) 

I mean define some sub part of the object that can be
recovered to the whole.  If a sub piece doesn't at
least have a pointer to the base, where is this info
stored?


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

This means passing around only the most basic object
defeating the cast checking system.  

(separate idea) How do you export
specific pieces of the interface?  For example, a frame
has 2 container interfaces.  I want to pass one of them
to something that is going to add a dialog in.  How would
I code that?  How would that reference so that it could
call signals? 

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

I really don't like this example much.  You are enforcing
entirely in the run time.  I would much perfer...

 void
 gtk_radio_set_active (GtkRadioIntf *object, gboolean active)
 {
   g_return_if_fail( GTK_IS_RADIO_INTF(object));

   GTK_GET_RADIO(object)->set_active (object, active);
 }

That way the user knows what must go in from the start.  (Gtk--
crew is a bit bitter about having to read through all 
the code just to find out the acceptable types and when the
types get derived having them change kills us completely.)

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

Kind of.  I am thinking of interfaces as being mini objects.  
An object be made up of composites of those mini objects or
it may export a mini-object as a part of it self.  Thus if
I have 

  void place_tic_tack_toe(GtkContainerIntf* w);  
   /* builds a tree interface in w */  

It can work with w if w is the window, a frame, or one side of
a paned.  Clearly, this is powerful abstraction as I don't
need special functions to export
  
  place_tic_tack_toe(paned.side1);
                                      

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

Well, I have other suggestions on radio groups.  It
would be better to make a group of toggles then build
a special radio for all these things.

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

I intend to solve that by introducing proxies.  They
are an addition to the gos type system were if it can't
find something it goes to the base object to get it.  Thus
exporting interfaces is as easy as deriving from a ProxyObject
instead of a real one.
  
 
> > 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.

I was just saying that if there was data associated with
an interface (for example, some drag interface may need 
to store scratch info).  Otherwise, this means that 
every thing that uses the interface may have to code
the method.  I was hoping that we can make the interface
then some implementations that use it (perhaps in abstract)
so that we don't need to do all this copy/paste/modify stuff.

gtk+ has too much of this already.  It would be simpler if
we borrowed the good ideas from other kits like FLtk.  For
example, if I make a toggle interface I can just define
a Group that works on Toggle interfaces.  Then there need
be no concept of "radio" buttons.  I just place radio style
toggle buttons together with a "Group" object.  It is more
flexible and the code for the toggle is the same for every
thing that acts like a radio group.  I have been fighting
for days now because RadioMenuItems and RadioButtons work
differently!  (Boy, won't that simplify the Packer demo a
bit as the toggles could all be grouped.)

Regards,

--Karl