Re: CTree inheritance from CList

[Owen Taylor <otaylor redhat com>]

Lars Hamann <lars@gtk.org> writes:

> On Tue, Aug 04, 1998 at 05:06:13PM -0400, Elliot Lee wrote:
> > On Mon, 3 Aug 1998, Lars Hamann wrote:
> > 
> > > Out of gtkclist.c :
> > > 
> > > /* re-send the selected signal if data is changed/added
> > >  * so the application can respond to the new data -- 
> > >  * this could be questionable behavior */
> > > 
> > > I'm not to happy with this selection signal, so I left it out for ctree.
> > > We can change that, if that's terribly wrong.
> > 
> > My big point was that since you are inheriting from CList, you are
> > required to support all the gtk_clist methods (including them being called
> > via the gtk_clist_methodname() functions), and the semantics thereof.
> 
> Sorry, that sounds to me esoteric somehow. A function is a function,
> is a function. It's no class method. With your argumentation we have
> to skip gtk_clist_remove too, because GtkCList is a GtkContainer and
> and GtkContainer defines :
> 
> void gtk_container_remove (GtkContainer *container,
>                            GtkWidget    *widget);
> 
> while GtkCList does :
> 
> void gtk_clist_remove (GtkCList *clist,
> 		               gint      row);
> 

Exactly. gtk_clist_remove() was a mistake.

Many functions in GTK+ _are_ class methods, and because we do
want to map these into "real" OO languages, the methods
of a class should be distinct from those of it's base
classes.

(Perl and C++ allow overriding ambiguous cases, i.e. in 
 Perl:
  
 $clist->CList::remove(row)

Perhaps ObjC does too - but we should be trying to
avoid this when at all possible)

Regards,
                                        Owen