Re: New 'GObject' as base for GtkObject?

[Karl Nelson <kenelson ece ucdavis edu>]

> 
> 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.

Sorry, I was trying the crank it out before the topic died.
I can provide additional info.  Obviously though it is not
a complete system.  I only demonstrated having both the object
and class info constructed separately.  I would have to demonstrate
how you set up a proxy so that part of the object could be exported
as an interface.

                       ___________
   __________         | ( Class C)|
  | ( Obj C )|        | _________ |         ____________
  | ________ |        || TypePtr ||------->| TypeA Base |@
  ||TypePtr ||------->|| CastInfo||--O     | A vfunc    |
  ||A data  ||        || A vfunc ||  |     |____________|
  ||(Obj A )||        ||_________||  |
  ||________||        | _________ |  |      ____________
  | ________ |        || TypePtr ||------->| TypeB Base |@
  ||TypePtr ||------->|| CastInfo||--O     | B vfunc    |
  ||B data  ||        || B vfunc ||  |     |____________|
  ||(Obj B) ||        ||_________||  |
  ||________||        | _________ |  |     
  | ________ |------->||TypePtr  ||@ |
  ||TypePtr ||        ||CastInfo ||  |     
  ||C data  ||        ||C vfunc  ||  |      
  ||________||        ||_________||  |
  |__________|        |___________|  |
                                     |     ________
                                     O--->| Info   |
                                          | Size   |
                                          | Tree[] |
                                          |________|
@ = pointer to itself

This is a picture of either 

   A   B
    \ /
     C

or 
     A
     |
     B
     |
     C

Each of the boxes in the composite are created by the user.
The system is responsible for grouping and joining.  
A type tree is constructed for binary searching at each
level in the hierarchy.


I meant for you just to look at the idea of the examples and ask
for specifics of the structure if the idea was close enough
to discuss.

  
> 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.)

Yes, as stated in the code it was a linear search, but
clearly was intended to be coded as a binary.  (I have the
start and end point in an array so coding binary search would
be just one or two more lines.)

> Disadvantages:
> 
>  - Its quite incompatible with the existing GTK+ 
>    system. (Common uses would look similar, but
>    all object structures and initialization would
>    require changes)

Yes, all the gtk+ objects would need at least some
changes.  User code that makes use of those objects
assuming they were following the Gtk+ conventions 
would not need to change.
   
>  - Casts are more expensive in all cases then current
>    casts, and function-call overhead can't be
>    removed in the non-debug case.

I am not sure about the first part of the statement as
I never have gotten a clear picture of how the gtk+ lookup
work.  This system has the advantage that for casting to
something always has a name of the type it came from and
thus it can be done just by direct table lookup by the level.
(I am guessing that gtk+ is similar.)  The second part of
the statement is very true unless SI optimizations are
added. 

 
>  - There is more memory overhead than the current system,
>    though I haven't examined just how much more.

Definitely more.  Each layer costs one pointer so if
something has three base classes it would have 4 pointers
"wasted" on type info.  However, I doubt that an MI system
without the support of the compiler can have less.

>  - 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.)

You could always get that info by looking at the Type
pointer in the class.  This also tells you if the type has
been derived.  If the type pointer does not equal the 
type pointer in the class (does not wrap back to self)
then the type was derived.

>  - 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

I am guessing that it is a complete wash.  Those languages
that wrap the gtk+ tree now with less than full Object systems
likely just wrap the functional level and none of the internals.
Since the gtk+ tree is an SI one the most that we would
do would be to pull away those common pieces like getting
and setting adjustment methods into groups for gtk+ 2.0.  
Since that just gives common names to functions, it would 
be mappable to a largely SI tree. 


Excellent, your analysis is right on.  Those are both the 
advantages and disadvantages that I meant to bring out.


> > 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.

Well, for some reason any mention of MI brings up the C++
version where you may have many pieces of the same type or other
such things.  I am just saying it was heading for the Java like
were you restrict it to a limited form.  (Pure virtual inheritance
here.)

(Selling C++ MI here is like trying to market air conditioners 
to Eskimos!)


> 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.)

I certainly hope that object interfaces aren't entirely flat.  If
I were to architect what I considered the perfect architecture 
the layers would always be about 4 levels deep.

  Defines           Implements        brings 
  basic         =>  interactions  =>  together    => Exports 
  interfaces                          pieces         Finished
                                      and  interactions

Thus it would be like

  Object  ->       Non Proxy                  Button
                              \             /
    \  \                       ButtonProto 
     \   Area    -> X Window   /            \ 
      \          /                            ToggleButton
       Events  /

(Object just has methods for accessing the get/set_data and 
reference but not the members themselves.)

I still do not understand how your simpler multi-interface could work.
If I export some piece of the class then casing it would have to
somehow know how to get back the base object.  This meant either
passing 2 pieces of info (base object location, specific type)
or in my case having internal runtime tables to use only one
piece of info. 

If your system is going to have the user create the tables 
then I would question that the system is too open to abuse
or clever use.  By not letting the user name anything but
the types separately I was hoping to defeat playing with internals
or the "I know were it is really located so I will short cut"
syndrome that plagues us in Gtk--.  Gtk+ already is too
open to "clever" uses.


Can you compose a demo of the system like the gos which shows
and example with some simple use?  It would both help
me see how easy it is to wrap in C++ and what design
decisions are left to be ironed out. 

Regards,

--Karl