Re: Classes for fundamental types, renaming GtkArg

[Marius Vollmer <mvo zagadka ping de>]

Tim Janik <timj@gtk.org> writes:

> On 25 Aug 1998, Marius Vollmer wrote:
> 
> >       info.reserved_1 = values;
> >       ^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > What about using the `klass' field of the GtkTypeNode for this?  Feels
> > cleaner.
> 
> currently, the use of the reserved_1 field is just an implementation issue,
> and info.klass==NULL already has indeed a very meaning.

As far as I can see, klass == NULL means that the class hasn't been
initialized yet, right?  I see no problem with that.  Setting klass to
the enum values would indicate that the class has been initialized
(which is true) and it will be left alone.  Because classes are never
freed I think it might even just work without changing a single line
of gtktypeutils.c.

We must make sure that no code gets confused because it expects all
classes to be derived from GtkObjectClass, but no correct code should
exist outside of gtktypeutil.c that deals with the classes of
non-GTK_TYPE_OBJECT-derived types.
 
> basically, this is a good idea. the actuall class structures, though,
> have to at least adhear to something like the `GtkTypeBaseClass' structure,
> i refer to in one of my last mails "Subject: hook functions (Re: Sound
>  events in Gtk)".

Should be no problem and might in fact bring even more uniformity to
the type system.
 
> > I think at least touching all enum literals can be avoided and the
> > long list of GTK_TYPE_* variables can probably be reduced to a
> > single one.
> 
> what do you actually intend to do to make this happen?

There is this code in gtktypeutils.c

      i = 0;
      while (values[i].value_name)
	i++;
      
      g_assert (values[i].value_name == NULL && values[i].value_nick == NULL);

I think we can just remove it or activate it in debugging versions of
Gtk only.  But when GtkEnumValue is combined with GtkTypeBaseClass we
again have to touch it on initialization.  I have no idea how costly
this is, and the pages should be shared anyway.

The variables currently defined in gtktypebuiltins_vars.c could be
replaced by macros like

    #define GTK_TYPE_CELL_TYPE  (_gtk_builtin_enums_base+0*GTK_TYPE_SEQNO_INC)
    #define GTK_TYPE_C_TREE_POS (_gtk_builtin_enums_base+1*GTK_TYPE_SEQNO_INC)
    ...

but I do no longer think that would buy us anything.

> > And I more and more dislike the name GtkArg.  I would like to rename
> > it to GtkValue.  What is now called `object args' should be called
> > `object attributes'.  While I'm all for source compatability, I think
> > that Gtk is still too young to develop anachronitis.
> 
> even across the 1.0 border we've already been keeping some API and naming
> oddities that would have been nicer other ways from the start on.

Ok.

> apart from that, an "argument" usually has a defined name, type and value
> (well, the actuall value can and should certainly vary), so "GtkValue" would
> definitively be a bad name, as it omits the type and name implications.

In dynamically typed languages, types are actually associated with
values, not with storage locations.  We should make the Gtk type
system be a dynamic one.  So this leaves the name.  I think the only
place where the name field of an GtkArg is used in Gtk is for the
object arguments and the container-child-arguments.  Signal handler
invocation (where the term `argument' would be appropriate and where
it originated I'm sure) does not use the name but instead identifies
the arguments by position.

The object argument code in fact doesn't really use the name of the
GtkArg structure either.  Instead, it uses the numerical arg_id of the
corresponding GtkArgInfo structure.  And, if you ask me, this is how
it should be.  The GtkArgInfo describes the argument (including some
flags that aren't in GtkArg) and GtkArg is a value that corresponds to
some GtkArgInfo.

The only real use for the name of an GtkArg is the handling of the
"signal" argument.  In my view, signals should not be handled by the
argument mechanism because they have a much richer semantic than just
being a slot that can be set to some value.

That does not address the fact that being able to deal with variable
names in the *_set_arg routines might be useful nevertheless.  But I
do think that encoding part of the value in the name of an argument is
a sign that one is stretching the idea too far.  The argument setting
abstraction can not cover the complete interface of every widget.  I
wouldn't mind if the "signal" argument of GtkObject goes away, as it
would clear up a potential trouble spot.

But regardless whether GtkArg looses its name field, I think its job
is better described as GtkValue.  I know, doing this renaming will be
tough and provide only little benefit, but I still want to voice my
opinion that GtkArg is a *bad* name, all things considered.

I'm not doing this totally light heartedly.  There are probably a lot
of places in Gtk that could benefit from a little improved
terminology.  But GtkArg is a very fundamental concept and visible to
the typical user only in the form of `object arguments' (I think only
language binders will see the inner workings of the signal apparatus).
For this purpose--that of setting individual fields of a data
structure--the term `argument' is totally confusing.

Luckily, the main thing is named gtk_object_set and not
gtk_object_set_arg.

So, even if we do not rename GtkArg to GtkValue, and all the various
*_arg functions to *_attr (which I could understand very well), we
should at least not call the things `object arguments' in the docs.