Re: Classes for fundamental types, renaming GtkArg

[Tim Janik <timj gtk org>]

On 26 Aug 1998, Marius Vollmer wrote:

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

if you intend to derive an enum class from GtkTypeBaseClass, which
holds pointers to the enum values, i see no problem with that.

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

yep, this should be removed somewhen, but since we are talking about the
development tree here, which actually implements lotsa new and experimental
stuff, it seems to be a good idea to leave extensive sanit checking in place
untill we get something like really-close to 1.2.

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

you are obviously not using the object arguments in C ;)

  entry =
    gtk_widget_new (GTK_TYPE_ENTRY,
                    "parent", hbox,
                    "visible", TRUE,
                    "object_signal::activate", gtk_window_activate_default, window,
                    "signal::destroy", gtk_widget_destroyed, &entry,
                    NULL);

is much compacter (and faster to type) than

  entry = gtk_entry_new ();
  gtk_container_add (GTK_COTAINER (hbox));
  gtk_widget_show (entry);
  gtk_signal_connect_object (GTK_OBJECT (entry),
                             "activate",
                             GTK_SIGNAL_FUNC (gtk_window_activate_default),
                             GTK_OBJECT (window));
  gtk_signal_connect (GTK_OBJECT (entry),
                      "destroy",
                      GTK_SIGNAL_FUNC (gtk_widget_destroyed),
                      &entry);

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

what is the potential "trouble" spot here?
the GtkObject::signal argument is a "special" argument in that
it is defined as wirite-only, so you can always special case
arguments like that.


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

well, your voice has certainly been noted, but i'm still far from
being convinced that we should cause major source incompatibilities,
just for a change that makes a certain sructure name nicer or more
descriptive.

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

the object arguments do certainly more than that, they export significant
portions of a widget's API in a *genric* way. the actuall goal is to 
approva a point where a widget builder and even source bindings can
access *any* widget in a generic way, without implementing special
knowledge for any of them.
also, the C code interface is, though not typesave, much more
convenient for the experienced Gtk programmer.

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

well, this would be questionable and should at least be reasonably
explained.

> 
> 

---
ciaoTJ