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:

> On 8 May 2001, Owen Taylor wrote:
> 
> > 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. 
> 
> fine, as we discovered on our irc meeting already, peter probably wasn't too
> consistent about this either (though not all of the above are actually his
> APIs).

Everything but gtk_curve and g_array, I believe. Like 16/4 better? ;-)
 
> anyways, apart from intuitiveness and order of significance where we obviously
> seem to disagree, the one reason why i certainly won't accept (bytes, n_bytes)
> ordering for the varargs case is that in a prototype with elipsis, e.g.
> 
> gpointer    g_object_set                      (gpointer        object,
>                                                const gchar    *first_property_name,
>                                                ...);
> 
> the compiler won't catch it if you make the wrong choice as a user (which _will_
> happen because we're inconsistent in other places already).

OK, so consistency is good.

> so since the compiler can't help the user here, the only aid i can give to
> him is consistency for the varargs APIs. now you can say "ok then lets always
> use (elements,n_elements) ordering for varargs interfaces and be done", but that
> doesn't account for e.g. lists. say i introduce a string list type, that would
> have to be collected as (n_strings, string1, string2, string3, ...) and with
> using (bytes,n_bytes) ordering for we'd get inconsistent in the varargs interface.

Do we have such a thing? I don't think so...

Are you about to introduce such a thing?

And would users really consider this the same as an array argument?

> putting examples, i don't want to confuse the user with:
> 
> g_object_set (object,
>               "list_property", n_items, item1, item2, item3,
>               "byte_property", bytes, n_bytes,
>               NULL);
> 
> but want him to be able to always pick the right order simply by knowing
> that for varargs we consistenly pick (n_elements, elements...), that is:
> 
> g_object_set (object,
>               "list_property", n_items, item1, item2, item3,
>               "byte_property", n_bytes, bytes,
>               NULL);
> 
> especially because we're talking a type-unsafe interface here, consistency
> is the only thing that can keep users from having to find out and remember
> individual orders by coding-running-segfaulting.

Even if you consider the above to be parellel, since the
"list_property" does not exist now, and we do have dozens, perhaps
hundreds, of functions like:

  void
  gtk_editable_insert_text (GtkEditable *editable,
			    const gchar *new_text,
			    gint         new_text_length,
			    gint        *position);

And like:

  char *strncpy (char *dest, const char *src, size_t n);

I would guess the more likely thing for people to do is to write:

 g_object_set (object,
               "byte_property", bytes, n_bytes,
               NULL);

Maybe I'm off in la-la land here, but I really don't think so...

Regards,
                                        Owen