Re: Proposal for a collection API in glib

["Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>]

2008/7/17 Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>:
> 2008/7/17 Havoc Pennington <hp pobox com>:
>> Hi,
>>
>> 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.
>>
>> 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.
>>
>> It would be possible to generically auto-create a GObject-based
>> iterator like yours, using this g-i feature.
>
> I am not sure I fully understand your proposal here. It would cater
> most for the bindings writers and not the C application developers,
> right?
>
> Also, if one where to use such a construct in C we would need a new
> external tool glib-gen-iterators. Please say it ain't so ;-)
>
>> 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 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.
>
> This idea is probably the one I like the most (also over Philip's
> original proposal), it has some problems though. The GBoxed
> implementation does a lookup based on the GType supplied to
> g_boxed_{copy,free}() to get the vtable for the implementation. This
> could mean that g_iter_next(GType type, gpointer iter) would have some
> overhead which might not be desirable for something we want to be as
> snappy as possible.
>
> This might be alleviated a little (or worsened) if we cache the vtable
> of the last call to g_iter_next() in a local static variable. Not
> sure.
>
> The same problem applies if we want to model a GCollection this way.

And here is a full proposal using the GBoxed technique (no, not the
drunken uncle technique, sorry):
http://live.gnome.org/MikkelKamstrup/GCollection

If one took of in gobject/gboxed.c it should not be that hard to do.
The work will probably lie in registering the existing collections as
GIterable<!-- -->s.

Cheers,
Mikkel