On Mon, Sep 1, 2008 at 11:18 AM, Murray Cumming <[EMAIL PROTECTED]> wrote: > > As I've told Johan, this won't be possible for significant amounts of > the API, because human thought really is required to make truly usable > APIs. And I worry that the auto-generation will create bad API that will > be declared stable and unbreakable without a maintainer ever even > looking at it.
Nothing prevents a binding maintainer from continuing to use a totally hand-coded approach on top of G-I, or a hybrid. As Johan said, I think the most practical approach is going to be to expose the autogenerated API without modification, but *also* have auxiliary libraries which fix up some APIs to be nicer, or integrate with other libraries in one's platform. Personally though, I fairly strongly believe that the GObject world is simply too big now for individual language bindings to completely hand code on top of. Long ago we thought GObject would just be for GTK+, and GTK+, while huge, is not unmanageable for a small team of volunteer contributors. But that was then; today, we have a full virtual filesystem (Gio), database APIs (libgda), HTTP (libsoup), GPS location (libgypsy), next-generation UI frameworks (HippoCanvas, Clutter, GooCanvas...), multicast DNS (avahi), multimedia (GStreamer), etc. Maybe gtkmm can get away with it for C++ since it has C compatibility, but for everyone else, it's too big. Even if you disagree though, with G-I we can centralize all the currently duplicated work that binding maintainers do, and by having the metadata generation included in the indivdual libraries, we will encourage C authors to create bindable APIs and write metadata from the start, which will help everyone. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list