Re: GLib plans for the next cycle
- From: Philip Van Hoof <spam pvanhoof be>
- To: Matthias Clasen <matthias clasen gmail com>
- Cc: gtk-devel-list <gtk-devel-list gnome org>
- Subject: Re: GLib plans for the next cycle
- Date: Wed, 11 Feb 2009 13:16:19 +0100
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/.
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
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
] [Thread Prev