Proposal for a collection API in glib

[Philip Van Hoof <spam pvanhoof be>]

Hi there,

I would like to propose this API to go into glib/gio:

http://live.gnome.org/IteratorsAPI

A working implementation of it can be found here (just replace Gee.List
with GLib.Seq, as that is the name that we have for it in mind):

http://svn.gnome.org/viewvc/libgee/trunk/gee/

To see users of this API, take a look at for example the Vala project.
On the IteratorsAPI wiki page, at the bottom, there are also a lot of
examples of projects that are right now inventing their own collections.

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

A normal use-case would be a GObject in a sequence, which would with the
caller-owns API 'g_iterator_get' mean that you need to unref what you
get. We are thinking about making it possible to pass a 'free-function'
to the owner of the items (the collection), and to allow annotating how
to free what you get from 'g_iterator_get' (as it's caller owns).

Right now, with the usage of GHashTable, GPtrArray and GList, language
binding developers loose all meaningful type information.

This means that they have to resort to using manually written glue code.
This is among the reasons that makes fully automated language binding
generation a nearly impossible task at this moment. 

In my opinion it's one of the reasons why we never really achieved
topnotch compelling language bindings, even though that was the #1
promise of Gtk+ back when it all started. 

It's of course debatable whether or not they topnotch. They are not for
me and having a collection API that actually does make sense outside of
the C world would in my opinion be one more step in the direct direction
of improving this situation.

This of course doesn't "magically" fix existing Cism APIs. But take a
look at the wiki page mentioned above for example on how this can easily
be improved.


Thanks, and please don't troll about how great doubly linked lists are. 

It's not the point.


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