Re: New 'GObject' as base for GtkObject?

[Owen Taylor <otaylor redhat com>]

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

> I have not heard back anything on my proposed object structure
> located at 
> 
>   http://www.ece.ucdavis.edu/~kenelson/private/gos.tar.gz

Hmmm, I don't see any docs - just some header files and 
c files. So I've had to spend some time puzzling out the
code, and I'm not really sure what is being proposed.

But from what I can figure out, there are some advantages,
and some disadvantages:

Advantages:

 - By making in-memory layout runtime rather than compile-time,
   the fragile-base problem that GTK+ (and C++) suffer from
   is largely alleviated. You should be able to add extra
   data members and functions to the end of base classes
   without breaking binary compatilibity.

 - You get pretty complete multiple inheritance with
   moderately cheap casts. (Not constant time, but 
   typically small searches.)

Disadvantages:

 - Its quite incompatible with the existing GTK+ 
   system. (Common uses would look similar, but
   all object structures and initialization would
   require changes)
  
 - Casts are more expensive in all cases then current
   casts, and function-call overhead can't be
   removed in the non-debug case.

 - There is more memory overhead than the current system,
   though I haven't examined just how much more.
  
 - Objects are no longer represented by a unique pointer.
   (though you can always get a unique pointer by 
   casting to a universal base class if such exists.)
  
 - Language bindings may be difficult depending on how
   well a language maps to this model. (The only 
   interpreted language I know the internals of well
   enough to judge  this for is Perl, where it would not be much
   of a problem, but it may be worse for other languages

> It is flexible enough that you can use it for multiple inheritance,
> inheritance of abstract interfaces, and multiple exportable interfaces. 
> It is very java like in construction with virtual inheritance only
> (not C++ like).  It demonstrates that only very simple tables are 
> necessary.

OK, I'm lost here. Java, as far as I know allows no
multiple-inheritance of implementation, while you are jumping through
large hoops to achieve multiple inheritance of data and member
functions.

I think what you mean by having only virtual inheritance, is that
there is only one copy of each base class in the derived object, but I
don't really see how this makes it Java-like.

But my basic opinion is that while it is neat, it is certainly far too
drastic a change to go into GTK+ in the near future ... it would
require rewriting large amounts of code in a very non-gradual fashion.

Also, right now I have no particular interest in having full multiple
inheritance of implementation within in GTK+, and I'm rather confident
that if all you want is multiple interfaces, then it is possible to
design something that is simpler and faster then gos. (Note that that
in the case where your object heirarchies are flat, the ->level
optimization buys you nothing and you just get a fairly simple
implementation of multiple interface lookup via a binary search in an
array.)

Regards,
                                        Owen