Re: GLib plans for the next cycle

[Philip Van Hoof <spam pvanhoof be>]

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