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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list