Re: [gtkmm] Wrapping by direct inheritance

[Karl Nelson <kenelson ece ucdavis edu>]

> On Fri, 13 Aug 1999, Karl Nelson wrote:
> 
> > In message <199908130424.GAA17961%timj@gtk.org>Tim Janik writes
[...]
> 
> GtkObject is not a particularly lightweight structure, it always comes
> with the signal handling abilities and also the classed type system
> overhead, thus it is often undesired to derive auxillary structures
> from it.
> i do understand your desire to not wrap every structure and its
> ref/unref functions though. i'm not sure how to handle that issue
> more effectively, maybe we could create a new AuxBase structure
> that we derive *small* structures from and that language wrappers
> can wrap consistently:
> 
[...]
> 
> language wrappers like gtkmm can then deal with these structures
> consistenly to a limited extend, that is, they always know how to
> ref and unref them, and have an ability to store wrapper data
> pointers and always get destroy notification. btw, GtkObject could
> *not* be implemented in terms of GAuxBase.

That is alright, I would gladly take having to wrap 2 types of 
objects over 10.


> though this may be suitable to help you to a certain extend, i'm not
> sure whether an approach like this is at all feasibly or would just
> add bloat without real benefit.
> there'd also be a certain transition time involved (such
> a change could of course only be done in 1.3) and i'm sure there
> are a bunch of people that will dislike the added overhead (thus
> the excessive quoting and Cc:-ing gtk-devel-list).

Well here is would be best to ask the others as well as
see if this will benifit the other wrappers.  Based on your
code above I am not sure that the overhead would be at all
significant.  The data structure is there in all gdk objects
already so its overhead is paid for on all by some of the 
gtk aux objects.  


> karl, i'm not sure we need the VTables with ref/unref at all,
> please comment on that.

Having the vtable would help greatly.  (although it would be
a while for the benifit to show.)  


> you certainly won't get a type id within all the auxillary
> structures, but a GData* pointer could be provided for most cases,
> would that be sufficient?

Having the vtable is enough to uniquely identify each object type.  
If you added a get_type function that returns a pointer
to the static structure which holds the vtable (which moves it
our of the initialized anyway), then that becomes the unique
types id.  Given that we can construct our own translation tables.

--Karl