Re: The runtime type system

[Tim Janik <timj gtk org>]

On Thu, 22 Oct 1998, Lauri Alanko wrote:

> Hello.
> 
> Am I mistaken, or is there no way of registering new boxed values? There are a
> couple registered in gtktypebuiltins, but there is no exported function for
> registering more in run time. Is there some reason for this?

new boxed types can actually be created through gtk_type_unique() similar to
objects, but you are right in that there should be an extra function for this,
since the GtkTypeInfo fields are nearly unused and gtk_type_unique() was
originally only intended to reister objects (as was the whole type system).

> Also, wouldn't there be some sense in allowing subtyping for more of
> fundamental gtk types? Runtime information of a more exact type of a callback
> or a signal might be useful at times. Each type could have a param type list
> and marshaller associated with them.

that's also a good idea, a very simplistic example of this is
GTK_TYPE_IDENTIFIER (in gtktypeutils.c: gtk_identifier_get_type() though this
still uses internal functions).
there are a few more shortcomings (better: bugs) in the current system, i.e.
newly registered third party fundamental types don't get a correct sequential
number assigned, it varies with the amount of derived types already registered,
where the actuall value realy should be GTK_TYPE_OBJECT plus some small number
up to 256.

> I'm a bit befuddled by the dynamic arg system, too. Semantically, it exports
> abstract attributes which have a type and which can be read and set, but this
> is implemented as a rather complex dispatch system which may do a lot more
> than just get or set a struct member. Seems like the worst of both worlds to
> me.

actually it tries to combine the best of both worlds. arguments serve a lot of
purpose (nowadays), i.e. pseudo-overloading is featured by omitting the class
specifier from the arg name, it also exports widget properties to GUI builders,
including an alternative interface to the constructor settings of a widget and
last but not least it is a convenient interface for some frequently used object
operations (e.g. the "GtkObject::object_signal" argument).

> I would have expected either a simple semi-automated system for accessing a
> member of a struct with known offset and type, or then a real dynamic method
> dispatch with multiple parameters, similar to the signal system. What's the
> reasoning with the current system.

granted, to get all of these functionalities implemented, a certain complexity
is involved along with a half decent value collection and dispatchment system,
but imho this is the best way to implement all of the above purposes through
one interface.
a generic interface to access certain structure members wouldn't be sufficient
because for 98% of the arguments, additional widget specific action is required
to either enforce the arguments value in the widgets layout, or to keep the
widgets internal data consistent.

> Oh, one more thing: is GTK_RUN_ACTION really just a keyboard
> accelerator-specific kludge? If so, is there any chance of moving it out from
> GtkSignalRunType? If this continues, the separation of the object and widget
> systems will become real hard later on..

GTK_RUN_ACTION has a valid place in GtkSignalRunType. it is meant to flag
signals that maybe emitted on an object without the requirement of special
assistance code outside of the emission (e.g. you couldn't emit "realize"
on a widget without first setting up its styles etc...).
it just happens that the key binding interface is obviously the most
appropriate one that would want to emit different signals on a widget at will.

the separation of widget and gdk specific code has actually cleanly been
enforced throughout the past. the separation of the object system is still
a reachworthy (is that a word? ;) goal and chances are that this will have been
done in an 1.2 release. the main issues of the sepeartion of the type and object
systems are about a GLib implementation of a generic event loop system along
with a generic input mechanism (a front end to poll() or select()) and a type
system separation regarding widget specific builtin types.

> Lauri Alanko
> la@iki.fi
> 

---
ciaoTJ