Re: New 'GObject' as base for GtkObject?

[Bill Huey <billh burn ucsd edu>]

> The reason I think that refcounting should not be in the base
> object is the multiple interfaces.  If I pass an interface to

This is good unless GtkObject starts to implements garbage
collection, then it must be within GtkObject.

> 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


If GtkObject was to either implement a C level Run Time Type Information
like in C++ (amoungst many other languages) one could do:

virtual_function = gtk_dynamic_cast( TARGET_L_VALUE_TYPE, derived_MI_object );

and have a dynamic message passing subsystem within Gtk resolve
various "message sends" and then cache or JIT that message resolutions
for faster performance.

The current GtkObject derived class definitions have a syntactically similar
convnetion, but it won't be able to throw runtime casting exceptions since
they are macroed to be (void) or something and are pretty much compiled out.

The use of that dynamic typing system could easily use the internal
type information and run-time resolve all multipule inheritence scenarios
very simply. That's what a typing system is suppose to do.

The Gtk crew is pretty much following what I know is the Java Native
methods interface in the C language.

I suggest looking at "jni.h" for a C based representation of a runtime
typing system that's superior to static typing systems that lack
some notions of compiler base "concrete type inference".

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

The conservativism of the GtkObject crew is just complete out of hand
and painful to listen to.

I don't see how this technology is going to compete with ActiveX from
MS, etc...

bill

> --Karl