On Thu, 2008-07-17 at 13:37 -0400, Havoc Pennington wrote: Hey Havoc,
> 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. You could make a GLib.Iterator that uses gobject-introspection, but I don't think you want to make gobject-introspection the one thing everybody who wants to expose collections in his API has to use and learn. - Make simple things, the usual use cases, easy - Make complex things possible This comes from "Framework design guidelines" by Krzysztof Cwalina and Brad Adams. I'm in agreement with that. It's to be honest what .NET (and Java) is getting right, and we don't. GObject-introspection on GList, GHashTable, GPtrArray and GSList wont be simple. Well, for a C developer being an expert in GObject-introspection and glib it might look simple. Those people should not be our only target audience when we are tagging application developers, though. > 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. Disagree with this. GObject-introspection can be an aid for the many quirks and Cisms our platform introduces. Future APIs should not focus on just the C application developers. It'll also be useful for other tasks that right now require scripts to parse C code, as gobject-introspection will ship with a bunch of very interesting tools for that (representing an existing API as an XML that will be suitable to throw at a XSL compiler). If GLib library authors wont focus on higher programming languages, then I fear Gtk+ and its accompanying large set of excellent libraries will get more and more neglected. But that's just my personal feeling. It is what excites me most about projects like Vala: they open the eyes of many C/GLib developers. Same thing about Tim's proposal to have a IDL above all of GLib and Gtk+'s .h files. The IDL will force developers to rethink their public APIs drastically (as they'll see how difficult they have made it for higher programming language users). I don't know why only C/GLib experts should be the ones writing language bindings (which is the case right now). It's quite hard to find people who are into the higher language and yet know really a lot about GLib too. Usually these people have no reason whatsoever to care about GLib and its isms anymore. Usually the language binding developer provides sugar to get rid of the GLib isms. Perhaps that's because they are ugly in modern programming environments? Relatively few people use doubly linked lists in C#, for example. Vala is an excellent example of how community people who are true black art masters and experts in GLib/GObject can provide excellent language bindings. Its tools just generate the vast majority! And the VAPI files are just Vala code like any other. Just without the function bodies. For special stuff you usually have an attribute (like C# has attributes) to finetune the behaviour of valac to cope with the Cism. > It would be possible to generically auto-create a GObject-based > iterator like yours, using this g-i feature. Yes. This I agree with. > 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 might be doable... I'll think about this proposal a bit more. > 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. *nods* > 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 Agree with this. Perhaps a more lightweight GType could be used for the iterator type. Isn't GStreamer for example providing lightweight GObject like GTypes? > * the need to unref the iterator is onerous for C programmers using iterators We should focus on higher programming languages for future APIs. For this caller owns makes most sense in my opinion. Cairo, behdad told me, has an interesting callee-owns setup. I still think that for iterators caller-owns is the right way, though. Looking at the samples on that wiki page, I don't think that having to destroy the iterator is onerous. Just good programming. > * the need to subclass a GObject is onerous for C programmers creating > iterators It's implementing an interface instead of subclassing a GObject. With programming languages like Vala this is easy. And yes, I think projects like Vala, gtk-sharp (Mono), pygtk, gtkmm, etc are the future for application developers. Not C/Glib in .c files. Those of us who still develop in C/GLib have the GObject macros: static void my_iterator_g_iterator_iface_init (MyIteratorface *iface) { iface->next = ... ... } G_DEFINE_TYPE_WITH_CODE (MyIterator, my_iterator, G_TYPE_OBJECT, G_IMPLEMENT_INTERFACE (G_TYPE_ITERATOR, my_iterator_g_iterator_iface_init)) http://live.gnome.org/Vala/MultiImplementInC > * 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. I didn't mention deprecating this code ... Philip -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list