My thoughts on GRing
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gnome org
- Subject: My thoughts on GRing
- Date: Thu, 14 Nov 2002 12:52:36 -0500 (EST)
and followups. In particular, Joshua Pritikin includes:
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
I just don't see the benefits of GRing as being worth these
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.
] [Thread Prev