Hi, On Thu, Jul 17, 2008 at 2:06 PM, Philip Van Hoof <[EMAIL PROTECTED]> wrote: > 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.
I didn't mean that - I meant if you exposed collections you'd use GList or whatever, and g-i would know that it was a "GList of Foo", and g-i would generate an iterator around the list based on that. Then users of the g-i API for language bindings would see only the iterator. >> 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. g-i is not for C afaik. It's supposed to replace all the source-code-scanners and "defs" files and so forth different language bindings are using. It should be extended until it completely replaces those things. g-i allows dropping static stubs - all functions are invoked *through* g-i, and return values are marshaled with it also. > 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). Ideally all scanning (and merging in lookaside info) will happen in g-i, which will then have everything a binding needs in the binary typelib. > 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. We don't need to break C to support other languages. Most libs will keep being written in C, and lots of existing useful code is in C, so we should keep having good C support. I think the ideal situation for the desktop looks a lot like Firefox or Emacs or World of Warcraft for that matter, with a C/C++ core and the top layers (including most visible functionality) in an agile language. Well OK, if starting 100% from scratch, it might be more ideal to write everything to a single virtual machine - but we aren't starting from scratch, we're starting with millions of lines of existing useful C code. > 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. g-i should be able to include any code that is generic across all bindings. >> * 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 ... The point is that if we don't deprecate GList, as I think we can't, then we end up with duplication and bloat. (Two versions of all existing APIs, at minimum.) Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list