Re: G_TYPE_<unterminated-string> (was: Re: Status of 2.0 API freeze bugs)

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> >  (And of course, ::insert_text, the signal for which we wanted
> >  G_TYPE_BYTES to begin with)
> > 
> >  At least 20-30 more
> > 
> > Now, you may argue that a lot of this (though not nearly all of this)
> > is new API. But in any case, there is darn lot of this in this
> > order and I don't see changing it now, even if I was convinced
> > that it was right to do so.
> > 
> > The only exception to the uniform ordering I know of is gtk_widget_path
> > and friends, and that is sort of odd for other reasons because the
> > length refers to two strings.
> 
> i think we should better ask whether it's a good idea in the first place
> to reverse the (n_elements, elements) scheme for strings in gtk+, and then
> technically, G_TYPE_BYTES is not something storing strings per-se.
> 
> it'd be a pity to have G_TYPE_BYTES and G_TYPE_CHARACTERS when they
> only differ in the order they expected their length and contents args.

OK, let's forget about strings for now and look at the question of 
arrays in general:

Currently, it's clear that there is a considerable lack of unity:

 Pango, GDK, and much of GTK+ (GtkTextView, etc.), use the 'widget, n_widgets'
 ordering.

 GObject and other parts of GTK+ (GtkItemfactory, etc.) use the 'n_widgets, widgets'.

If you count the instances, the majority is certainly the first ordering,
but it's conceivable that this is something "new-fangled", and Havoc and
I have been rapidly adding API with stuff in the wrong order.

So, let's go back in history to August 1997, to about the time that Peter
turned over GTK+ maintenance:

 widgets, n_widgets: ~18 functions

  gdk_query_depths, gdk_query_visual_types, gdk_query_visuals, gdk_colors_alloc, 
  gdk_colors_free, gdk_colors_change, gdk_draw_polygon, gdk_draw_points, 
  gdk_selection_set, gdk_property_change, g_array_append_values,
  g_rarray_append, gtk_menu_factory_add_entries, gdk_menu_factory_remove_paths,
  gdk_menu_factory_remove_entries, gtk_object_class_add_signals
 
 n_widgets, widgets: ~6 functions    

  gtk_curve_set_vector, gtk_curve_get_vector, gtk_object_newv, gtk_object_setv,
  gtk_widget_newv, gtk_object_getv.

So, basically, the newv functions had one ordering, everything else had another
ordering. 

When you add in the fact that strings are 'string, length' both then and
now...

Regards,
                                                   Owen