Re: Proposal for a collection API in glib

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

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.



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
* the need to unref the iterator is onerous for C programmers using iterators
* the need to subclass a GObject is onerous for C programmers creating iterators
* 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.

Havoc