Multiple Inher vs Multiple Inter (was New 'GObject')

[Karl Nelson <kenelson ece ucdavis edu>]

> For this aggregation certainly works quite well. And with 
> multiple-inheritance of implementation, you will be in serious
> trouble if you have a widget that has _two_ text fields.

There can only be one unless you want a HasA in which case 
is aggregation HasA and not part of.  Though the 
problem of multiple text fields affects multiple inheritance
and multiple interfaces alike, unless you are thinking of some
other way to implement it. 
 
> > This approach also allows for a work allike, were you take a text 
> > interface and write your own implementation.  This is more
> > like multiple interface.
> > 
> > Of course there is another way to achieve the same effect.  That
> > is just to have only multiple interface that is exportable.  Then
> > the label in the frame is a real label that you export its
> > interface to the user.  (But then what happens when you want
> > a box instead of a label.)  
> 
> For 1.4 if you want to put a pixmap or a checkbutton, or a CList
> in the slot where the label currently goes, you'll be able to do 
> that.

Okay that sounds a lot better.
  
> > I think the right solution is to allow for multiple inhertance and
> > try to make lightweight objects that can be used in composition.
>  
> If you s/multiple inheritance/multiple interfaces/ than that
> is my basic opinion.

There is one place where multiple interfaces fails, and that
is where it implied some data member.  If for examples, signals
need some data storage then they wouldn't be allowed in the
interface.  Thus I think allowing for the inheritance should
be provisioned.  (Of course you can use the quarks and data
list to the same thing, but I don't know if that will be a
performance problem.)  
   
\[...]

> > GnomeApp comes from GtkWindow, but it has replaced the contents so
> > all the GtkWindow methods can't be used.  While GtkWindow is a
> > GtkContainer which can't have multiple contents, so the add method
> > means totally different things.  And the GtkContainer comes from
> > GtkWidget, but that has special functions for extracting info which
> > exists in only 3 widgets....
> 
> What 3 widgets are these? GtkWidget has a few hacks around
> the lack of multiple-interfaces, but they don't seem relevant here

(This is those adjustment kludges where some widgets have 
adjustments so to fake MI we give methods for all to get them.)

Those have created problems in Gtk-- from time to time as the
user assumes the function of them applies.  Clearly MInt will
solve this.  
 
> > Thus GnomeApp has dozens of methods that don't belong and are not
> > useful to down right harmful!  Clearly, GnomeApp which decends from
> > IsA window should have been a HasA window and works like (IsA) a
> > widget.
> 
> I don't see where GnomeApp has "dozens of methods that don't
> belong".

Maybe a slight exageration, but I am sure I could count a good
number.  Things like label with all the events that it can't
receive is far worse.  When you add the event box, you can
grab the events there, so there is no reason for passing them
down to a label.  Hopefully, with MInt we could split those
event interfaces into small sets.    

Giving out anything to the user that you take away at the next
level is horrible to me and the user.  The add is the classic
example.   I spent a day staring at some ones broken gnome
example just to figure out that somewhere a GnomeApp got 
down casted to a GtkWindow and then later passed to something
which performed an add.  

> Although there are problems with the functions from GtkContainer -
> every method from GtkWidget and GtkWindow works fine. 
> GtkContainer has only ~10 public methods, and some of these
> (gtk_container_set_border_width()) work fine. 

Good OO is that everything works that was given.  That doesn't
mean that it has to perform anything other the returning
you can't do that.  But it should never kill the system.  

One of my worst pet peeves with gtk+ is the container that
allows all widget types at one level and then later restricts
to small subsets.    

> There are still issues with composite widgets and
> gtk_container_add() / gtk_container_remove(), but I don't think
> those are inherent to the basic setup.
> 
> The basic setup is that a composite widget must derive from the
> outermost container, so that we can add it to another widget with a
> single gtk_container_add().

But you can't use a container_add on a composite widget or you
wipe out the contents of the composite and likely crash the
system.  I did the myself with GnomeApp.  Also all these things
that derive from Boxs and place special things in them.  You can
get the system in real trouble calling box remove on those required
sub pieces.  (This is really quibbling about the details, we
at least see eye to eye on the problem's existance.)

What would be wrong with having abstract container interfaces that you
pass arround?  In the case of a frame, you can pass the main interface
or the auxilary interface to the thing wishing to add.

> Now, this doesn't strictly apply to widgets that are toplevels
> such as GnomeApp ... GtkMenu is an example of such a widget 
> that does _not_ inherit from GtkWindow, but hasA GtkWindow
> instead. 
> 
> However, since we need to figure out how gtk_container_add() should
> work for composite widgets that are not toplevels, there is no
> advantage in doing something different for the toplevel composite
> widgets.

I think the problem is more wide spread.  All composites, not
just toplevels, have the problem of deriving and then using
the interworkings.  A few like messange  
 
> I think you have to accept that just occasionally there will
> be inherited methods that don't apply to all child types,
> and that you may need runtime warnings. I would consider
> these small quirks rather than complete meltdowns of
> the OO system. 

I don't have time to dig up all the questions that resulted
from those "quirks".  But as long as we are willing to 
remove those quirks over time, it is acceptable to me.

--Karl