Re: Proposal for a collection API in glib
- From: Philip Van Hoof <spam pvanhoof be>
- To: gtk-devel-list <gtk-devel-list gnome org>
- Cc: Tim Janik <timj imendio com>
- Subject: Re: Proposal for a collection API in glib
- Date: Thu, 24 Jul 2008 20:36:49 +0200
So,
Do we have a conclusion on this proposal?
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);
>
> 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]