Re: Proposal for a collection API in glib

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

2008/7/21 Steve Frécinaux <nudrema gmail com>:
>> 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.
>
> I don't understand why the GType appears in the function call for
> g_iter_next(). As I understand it, a GIter will always be used to
> iterate on a single object, thus the GType should be a struct member
> of its.
>
> Thus you'd have something like the GtkTreeIter:
>
> GIter foo;
> foobar_get_iter (foo);
> while (g_iter_has_next (foo)) {
>  gpointer elt = g_iter_next (foo);
>  ...
> }

Right. It is not obvious why I need the GType argument, but there is a
reason for it (although whether or not it is the right thing to do can
certainly be discussed):

Obviously the GType argument is used to look up the the right vtable
for the iterable. My idea was to _not_ require a g_iter_init()-like
call, but be able to use the GIter directly with out initialization
(and have that done automagically inside iter_next() and
iter_has_next()), so one could just do:

GIter iter = {0,};

while (g_iter_has_next (type,& iter, iterable)) {
    g_printf ("%s\n", g_iter_next(type, &iter, iterable));
}

With a g_iter_init (GType type, GIter *iter, gpointer iterable) we
could strip the 'type' and 'iterable' arguments from the
g_iter_{has,}next() methods though, so the price I pay is quite high.
Perhaps too high.

The idea of using the (Gtype, GIter, gpointer) signature was also to
keep it aligned with GBoxed. If we move away from this it might be
better to simply use GType interfaces (without full GObjects (as I
also discussed with Jurg on IRC)).

Cheers,
Mikkel