Re: New 'GObject' as base for GtkObject?

[Karl Nelson <kenelson ece ucdavis edu>]

> > I was thinking more allong the line of a multiple inheritance system
> > where the base size was 4 bytes.  (pointer to the class)  This is
> > below an object.  Sets of bases can be combined through SI or virtual MI.
> > Although it is easier to define things that are always MI.  (thus
> > preventing the problems that C++ gets into of having multiple copies
> > within the classes.  Okay this is hard to imagine... I will
> > compose a small sample system this weekend with those properties to
> > give you an idea what I mean. 
> 
> multiple inheritance will definitely not be going into the libgobject
> logic, for one this is an extremely tedious thing to imlement in C
> efficiently and complexifies structure accesses by a significant
> amount, and for another the existing GtkObject system would be really
> hard to get going on top of that, if at all.
> and finally i guess there'd be some non-C++ language binders who
> are going to rip our asses off for that ;)

I don't quite understand why you think it complexifies the interface
all that much.  It took me only 2 hours to modify a simplified 
copy of the gtkobject system to have MI.  

  http://www.ece.ucdavis.edu/~kenelson/private/gos.tar.gz

The tabel implementation is just slightly more complex on the
initial creation (where building the tables is done) and then
it is just as simple and fast as SI for everything else.

The reason I think that refcounting should not be in the base
object is the multiple interfaces.  If I pass an interface to
a function and it needs to reference the object.  However,
since the interface as is a fragment of the object (more like
a HasA or HasMany), we don't want to reference just that
interface, but rather the object to which the interface belongs.
Therefore, either referencing needs to be virtual (as in my
MI implementation) or you must hardwire for the two cases,
Interface <=> Object and Interface is part of Object.

Under MI

    Ref + ContainerInterface => ContainerObject
    RefProxy + ContainerInterface => ContainerProxy

The other option without is to just put the reference countin
scheme into the data structure so that you can point two objects
to the same reference counter.  But I think that would over
complicate the data scheme.

So, before dismissing it completely, please take a look to see 
what I had in mind.

--Karl