Re: GObject-Introspection

["Colin Walters" <walters verbum org>]

On Mon, Sep 1, 2008 at 11:18 AM, Murray Cumming <murrayc murrayc com> 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.