No RedBull this time. Somebody more or less asked it. Poor you guys.
Returning a doubly linked lists is going to put your library at odds with higher programming languages like Java and .NET that don’t really have a corresponding type that can rapidly be converted in two directions from and to C and the higher programming language.
But who said that first of all, you need to return it. And second of all, that you can’t wrap it up in a GObject or GTypeInterface? I for sure didn’t.
So that is what I did for tinymail. I created both a TnyList and a TnyIterator interface. I’ve let my GtkTreeModel implementations also implement TnyList and created TnyIterator implementations for them.
The methods that give me a list of things, simply ask for the TnyList instance to fill up. Rather than return it (it could of course also return the one that it got from the parameters).
If now a language binding language binds the TnyList and TnyIterator API, just like other GTypeInterfaces and GObjects, everything will works just fine. Most language binding code generators do this automatically. If the proxy type being used by that binding implements the higher programming language’s list and iterator interfaces, the typical foreach and iterator patterns will work with it.
It’s one of those simple solutions for simple problems that very few people seem to tackle. Most people simply return a doubly linked list and that way burden the language binding creator with the task of supporting the method somehow in a typical C way internally in the proxy type.
A GObject really doesn’t consume a lot bytes. And you gain the freedom of how you’ll implement the list. You can still use a GList or GSList internally and enjoy the performance of that. You can also implement it as a btree or a skiplist perhaps. Depending on your mood, performance needs and the change that is a constant in the IT industry. Abstracting the list and iterator types using GTypeInterface makes your software more adaptive to changes. More flexible.
Hi, I see you and Johannes are getting creative :) How about coming up with a Collections API for glib. I remember the discussion during Guadec to move TreeModel to glib. I think a generic Collections API could solve that as well, in addition to the advantages you mentioned.
cheers,
Greg
Yes, these are indeed ideas that we are playing with. It’s btw not only me and Johannes. It’s you, Rob Taylor, Robert McQueen, me, Johannes and actually also the gnomevfs dudes who are planning to steer the VFS layer to stream-types.
I think it’s a movement happening. Which is good.