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