On Thu, 2008-07-17 at 12:46 -0400, Yu Feng wrote: > > > > 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?
GValue and other GBoxed solutions where measured by Jürg (Vala project) for performance. His analysis showed that boxing using GBoxed and/or GValue would be a lot slower (too slow). We would want the collection API to perform as fast as possible, or at least make it possible to have a high performing collection implementation: - Make it EASY (really easy) to make a normal performing one - Make it possible to make a high performance one > 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. Exactly. With this collection API, you'd have a very automatable and well known way to do reference management for the items that are owned by the collection. It's not the only reason, the other reason is that everybody seems to be reinventing iterator based APIs: In GLib + Gtk+ you already have three incompatible iterator APIs (or there will be three as soon as GVariant is going to be used by people); - GFileEnumerator - GVariant's iterators - GtkTreeModel If you add to that other projects, we get this interesting list: * Camel (CamelIterator) * libanjuta (IAnjutaIterable) * libedataserver (EIterator) * libgda (GdaDataModelIter) * libvala (using libgee) * Tinymail (TnyList and TnyIterator) * GVariant (g_variant_iter*, etc) * GIO (gfileenumerator.h) * Gtk+ (GtkTreeModel is an iterable) * Clutter and Tidy with ClutterModelIter * GStreamer with GstIterator Clearly, whoever decided that a collections API is not necessary (because GList, GSList, GHashTable and GPtrArray work just fine in C), must have made a significant error in his or her judgements. My conclusion (as usual, it's a harsh one) I think it's proven from not only the Java, C, C++ and C# world that a collections API is important, our own GLib based projects have and GLib itself has started inventing ad-hoc solutions around the lack of a generic collection API in glib. I'm not convinced that GList, GSList, GHashTable and GPtrArray are good components for making a sustainable and future proof API. Not convinced at all. Thanks for your reaction, Yu Feng. Philip -- 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
