On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote: > - What do we do about collections ? EggDbus adds typesafe GObject > wrappers around GHashTable and GArray. Other people have grandiose plans > to force java/.net style collection interfaces into GObject.
You are using the phrase "To force". Is this an indication that you personally don't like such collection APIs? If so, can you explain why? > My proposal: Dodge the issue by just adding the minimal necessities > to GObject: a type for GArray (GHashTable already has one), and an api > to associate element type information to arrays and hash tables. Applications may have different requirements for a collection API: o. Separate interface from implementation o. The current GLib datatypes are hard to use - no reference counting - no type information (GType and memory management) Although your proposal addresses the latter and makes sense for EggDBus's requirements, I don't see how it addresses the former. We have started a git branch that implements the proposal in gobject/. http://git.codethink.co.uk/?p=glib;a=shortlog;h=collections We are open to comments and proposals from the community. We plan to implement use-cases, like a GTreeModel, on top of this, at some point. Next to model-viewing widgets we have many other use-cases with which we will be experimenting in this git repo. Why is it an advantage to separate implementation from interface? First, why do we want one interface instead of many: - If you provide an API where you use a collection, it's important that when you change the implementation (of the collection), that your API doesn't have to change with it. This is a similar issue to Gtk+ exposing a lot implementation details in its API. - Bindings. Collection are usually bound in a special way to integrate with a higher language. - Consistency of the API. This makes it easier for app developers. Here's a list of examples with existing collection-like-apis: GVariant, GHashTable, G(S)List, GPtrArray, GArray, ... If we add a few (significant) libraries to the list, we get: Gtk+ : GtkTreeModel Clutter : ClutterModelIter Gee (Vala): GeeIterator, GeeIterable GStreamer : GstIterator Camel : CamelIterator EDS : EIterator Tinymail : TnyIterator, TnyIterable LibAnjuta : IAnjutaIterable This is the proposal, by the way: http://live.gnome.org/IteratorsAPI > When I sat down with David and tried to figure out what the minimal > necessities actually are, we came up with the following: > GLib GObject > > g_ptr_array_ref/unref > g_ptr_array_set_data > g_ptr_array_set_element_free_func > G_TYPE_PTR_ARRAY > g_ptr_array_set/get_element_type > > g_array_ref/unref > g_array_set_data > g_array_get_element_size > G_TYPE_ARRAY > g_array_set/get_element_type > g_array_new_with_type > > g_hash_table_set/get_key_type > g_hash_table_set/get_value_type > g_hash_table_new_with_types Greetings, Jürg and Philip (at a codecamp) -- 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