Re: Proposal for a collection API in glib

[Yu Feng <rainwoodman gmail com>]

Hi Tim,

On Thu, 2008-07-17 at 17:51 +0200, Philip Van Hoof wrote:
> 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);
> 

It looks like a GValue. Can it be simplified by using GValue?

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

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.

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