Re: New 'GObject' as base for GtkObject?
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list redhat com
- Subject: Re: New 'GObject' as base for GtkObject?
- Date: 21 Dec 1999 00:28:44 -0500
Karl Nelson <firstname.lastname@example.org> writes:
> I have not heard back anything on my proposed object structure
> located at
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:
- 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.)
- Its quite incompatible with the existing GTK+
system. (Common uses would look similar, but
all object structures and initialization would
- 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
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
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
] [Thread Prev