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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
