Re: Proposal for a collection API in glib

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2008-07-17 at 12:46 -0400, Yu Feng wrote:

> > 
> > We are working on adding convenience functions for C to make things as
> > type safe as possible (the #1 problem with glib's current collection
> > types):
> > 
> > gchar*  g_iterator_get_as_string (GIterator *iter);
> > gdouble g_iterator_get_as_double (GIterator *iter);
> > 
> 
> It looks like a GValue. Can it be simplified by using GValue?

GValue and other GBoxed solutions where measured by Jürg (Vala project)
for performance. 

His analysis showed that boxing using GBoxed and/or GValue would be a
lot slower (too slow). We would want the collection API to perform as
fast as possible, or at least make it possible to have a high performing
collection implementation:

 - Make it EASY (really easy) to make a normal performing one
 - Make it possible to make a high performance one

> I think the problem is that lacking of reference management, GList is
> not intended to be used in a language binding; whereas in the reality a
> lot of GTK APIs take and return GList, forcing the binding programmers
> to write glue code.

Exactly. With this collection API, you'd have a very automatable and
well known way to do reference management for the items that are owned
by the collection.

It's not the only reason, the other reason is that everybody seems to be
reinventing iterator based APIs:

In GLib + Gtk+ you already have three incompatible iterator APIs (or
there will be three as soon as GVariant is going to be used by people);

- GFileEnumerator
- GVariant's iterators
- GtkTreeModel

If you add to that other projects, we get this interesting list:

* Camel (CamelIterator) 
  * libanjuta (IAnjutaIterable) 
  * libedataserver (EIterator) 
  * libgda (GdaDataModelIter) 
  * libvala (using libgee) 
  * Tinymail (TnyList and TnyIterator) 
  * GVariant (g_variant_iter*, etc) 
  * GIO (gfileenumerator.h) 
  * Gtk+ (GtkTreeModel is an iterable) 
  * Clutter and Tidy with ClutterModelIter 
  * GStreamer with GstIterator

Clearly, whoever decided that a collections API is not necessary
(because GList, GSList, GHashTable and GPtrArray work just fine in C),
must have made a significant error in his or her judgements.


My conclusion (as usual, it's a harsh one)

I think it's proven from not only the Java, C, C++ and C# world that a
collections API is important, our own GLib based projects have and GLib
itself has started inventing ad-hoc solutions around the lack of a
generic collection API in glib.

I'm not convinced that GList, GSList, GHashTable and GPtrArray are good
components for making a sustainable and future proof API.

Not convinced at all.



Thanks for your reaction, Yu Feng.


Philip

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be