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

[Tim Janik <timj gtk org>]

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

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

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.


> 
> Regards,
>                                                    Owen
> 

---
ciaoTJ