My thoughts on GRing

[Owen Taylor <otaylor redhat com>]

Original discussion:

 http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00417.html

and followups. In particular, Joshua Pritikin includes:

 http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00451.html

in the tarball.


The arguments in favor of GRing seem to be:

 - Saves space. True, but not significant amounts ... just
   a 12-byte constant overhead.

 - It is more efficient. I dont think it matters for cases where
   you are keeping a permanent queue around. It is true.

    GSList *foo = NULL;

    foo = g_slist_prepend (list, a);
    foo = g_slist_prepend (list, b);
    foo = g_slist_prepend (list, c);

    foo = g_slist_reverse (foo);

   Would be more efficient and less confusing with GRing... but
   the problem with this is that if you are going to then pass
   the list, say, into GTK+, then you have to convert the 
   GRing to a GList/GSList, losing all the advantages.

 - Has the same API as GList/GSList. 

   Sort, of, but not exactly;
   [You can't use node->next, node->prev, as almost all G[L]ist
   code does, g_ring_prev() is named differently than g_list_previous(), and
   takes another argument, g_ring_insert_sorted() takes an extra user 
   data pointer, g_ring_insert_before() is missing, g_ring_first() 
   does something completely different, g_ring_nth_prev() does
   something completely different]

   Now, it could be argued that a lot of the above differences
   are just implementation details, and also, that a "GRing" that
   was more like GList could be done by using the 
   node->next->prev != NULL trick for reverse iteration (though
   "Ring" wouldn't be a good name then.)
  
   But still, GRing does differ from GList in significant ways.

 - Has the complete GList/GSList API, as opposed to GQueue,
   which has only a subset. How is this an advantage?
   We could trivially add the complete API to GQueue...
 
 - Is easier to use than GQueue. Well, only by virtue of similarity
   to GList/GSList ... newbies generally find GList utterly
   puzzling (try to use g_list_alloc() to allocate a new one,
   forget to assign the results of g_list_remove() or whatever
   back to the list point)

Is something like GRing a better way of implementing a double-ended
list than GQueue? Probably.

Would it make sense to have both GQueue and GRing as non-deprecated
API's in GLib? No. It would be silly. If we add GRing, we have
to plan on deprecating GQueue.

Is it worth the pain of deprecating GQueue and adding GRing? 
I don't think so. Deprecation is expensive both in terms of:

 - Requiring people to change their code
 - Confusing people until all vestiges of the deprecated method
   are removed.

I just don't see the benefits of GRing as being worth these
costs.

Regards,
                                        Owen


Even the Perl slogan "there's more than one way to do it", 
doesn't mean that you should have multiple almost identical
API's, but that if you have a flexible set of primitives, there
will be multiple ways of accomplishing the same end task.