Re: Proposal for a collection API in glib

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

2008/7/18 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.

On http://live.gnome.org/MikkelKamstrup/GCollection you will now find
a sample patch against trunk (rev 5882) implementing GIterable as
described on the page.

Cheers,
Mikkel