Re: Proposal for a collection API in glib

["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.

> <snip>
> * 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.

Does this mean that you/he believes that a collection/iterator api in
glib would be for bindings only, and that people would be better off
using the good olde constructs when doing C code? Or am I reading it
wrong?

Cheers,
Mikkel