Re: Proposal for a collection API in glib

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2008-07-17 at 13:37 -0400, Havoc Pennington wrote:

Hey Havoc,

> Here are some alternate ideas, just brainstorming:
> 
> 1) have an iterator concept in gobject-introspection and map from
> GList etc. in g-i. So g-i would allow you to invoke a method that
> returns a list, and get an iterator back.

You could make a GLib.Iterator that uses gobject-introspection, but I
don't think you want to make gobject-introspection the one thing
everybody who wants to expose collections in his API has to use and
learn.

  - Make simple things, the usual use cases, easy
  - Make complex things possible

This comes from "Framework design guidelines" by Krzysztof Cwalina and
Brad Adams. I'm in agreement with that.

It's to be honest what .NET (and Java) is getting right, and we don't.

GObject-introspection on GList, GHashTable, GPtrArray and GSList wont be
simple. Well, for a C developer being an expert in GObject-introspection
and glib it might look simple. Those people should not be our only
target audience when we are tagging application developers, though.

> If I were doing this in gobject-introspection I'd tend to make the
> base API use a stack-allocated lightweight iterator similar to
> GtkTreeIter/GtkTextIter, and then bindings that wanted to could write
> generic code to wrap that kind of lightweight iterator in a GObject.
> 
> Any language binding not using g-i has nothing to stand on if they
> whine about manual work - they need to a) port to / help with g-i and
> then b) we'll talk.

Disagree with this. GObject-introspection can be an aid for the many
quirks and Cisms our platform introduces. Future APIs should not focus
on just the C application developers.

It'll also be useful for other tasks that right now require scripts to
parse C code, as gobject-introspection will ship with a bunch of very
interesting tools for that (representing an existing API as an XML that
will be suitable to throw at a XSL compiler).

If GLib library authors wont focus on higher programming languages, then
I fear Gtk+ and its accompanying large set of excellent libraries will
get more and more neglected. But that's just my personal feeling.

It is what excites me most about projects like Vala: they open the eyes
of many C/GLib developers. Same thing about Tim's proposal to have a IDL
above all of GLib and Gtk+'s .h files. The IDL will force developers to
rethink their public APIs drastically (as they'll see how difficult they
have made it for higher programming language users).

I don't know why only C/GLib experts should be the ones writing language
bindings (which is the case right now). It's quite hard to find people
who are into the higher language and yet know really a lot about GLib
too. Usually these people have no reason whatsoever to care about GLib
and its isms anymore.

Usually the language binding developer provides sugar to get rid of the
GLib isms. Perhaps that's because they are ugly in modern programming
environments?

Relatively few people use doubly linked lists in C#, for example.

Vala is an excellent example of how community people who are true black
art masters and experts in GLib/GObject can provide excellent language
bindings. 

Its tools just generate the vast majority! And the VAPI files are just
Vala code like any other. Just without the function bodies. For special
stuff you usually have an attribute (like C# has attributes) to finetune
the behaviour of valac to cope with the Cism.

> It would be possible to generically auto-create a GObject-based
> iterator like yours, using this g-i feature.

Yes. This I agree with.

> 2) Another idea would be an equivalent to registering boxed types:

> g_iterator_type_register_static(const char *name, GBoxedCopyFunc
> boxed_copy, GBoxedFreeFunc boxed_free, GIteratorNextFunc
> iterator_next, GIteratorGetFunc iterator_get);

This might be doable... I'll think about this proposal a bit more.

> This would allow language bindings to generically manipulate custom
> iterator types like TextIter and TreeIter, without making things a
> pain in C and while keeping things lightweight. And without
> redoing/breaking TreeModelIter and TextIter and all the other existing
> examples you mention.

*nods*

> Why explore alternate ideas? Some downsides to GIterator-as-gobject:
> 
> * GObject is pretty heavyweight for something like this, and moreover
> right now libglib doesn't depend on libgobject

Agree with this. Perhaps a more lightweight GType could be used for the
iterator type. Isn't GStreamer for example providing lightweight GObject
like GTypes?

> * the need to unref the iterator is onerous for C programmers using iterators

We should focus on higher programming languages for future APIs. For
this caller owns makes most sense in my opinion. 

Cairo, behdad told me, has an interesting callee-owns setup. I still
think that for iterators caller-owns is the right way, though.

Looking at the samples on that wiki page, I don't think that having to
destroy the iterator is onerous. Just good programming.

> * the need to subclass a GObject is onerous for C programmers creating iterators

It's implementing an interface instead of subclassing a GObject. With
programming languages like Vala this is easy.

And yes, I think projects like Vala, gtk-sharp (Mono), pygtk, gtkmm, etc
are the future for application developers. Not C/Glib in .c files.

Those of us who still develop in C/GLib have the GObject macros:

static void
my_iterator_g_iterator_iface_init (MyIteratorface *iface)
{
        iface->next = ...
        ...
}

G_DEFINE_TYPE_WITH_CODE (MyIterator, 
        my_iterator, 
        G_TYPE_OBJECT,
        G_IMPLEMENT_INTERFACE (G_TYPE_ITERATOR,
                my_iterator_g_iterator_iface_init))

http://live.gnome.org/Vala/MultiImplementInC


> * as Owen mentioned long ago when this was already discussed, we'd end
> up duplicating bunches of APIs just to make them use iterators instead
> of whatever they use now - this is both bloat and confusing. It would
> not be realistic to ever deprecate walking GList etc. - the iterator
> replacement is much less convenient, and there's way, way, way too
> much code using GList already. You can't deprecate something that
> touches this much code.

I didn't mention deprecating this code ...


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