Re: [ANN] ocaml-gir 0.9 alpha - binding generator for glib2-based libs

Adrien <[email protected]> Tue, 13 Oct 2009 19:10:42 +0200
Newsgroups gmane.comp.lang.ocaml.lib.gtk
Message-ID <[email protected]>
On 12/10/2009, Stefano Zacchiroli <[email protected]> wrote:
> Out of curiosity, is there any specific reasons for not integrating
> ocaml-git tout court into lablgtk2?  IIUC the roadmap in front of GLib
> upstreams, GIR is pretty much an intimately part of it, what do we gain
> in keeping the projects separate?
>
> /me just thinking aloud
>

>From what I've seen, full gobject-introspection support should be
achieved by gtk4 (or maybe 3.5). Moreover, gobject-introspection as a
software is pretty bad: it changes the interface of the libraries and
if you run "make" inside gobject-introspection or gi-repository, you
may end up with something else than the library interface (ie the
interface to a bunch of .c and .h files which come with
gi-repository).

I'm not sure I like gobject-introspection as a concept either. Sure,
having a description of the libraries interfaces is nice but that's
already called gtk-doc (and the corresponding annotations), making
bindings on-the-fly (or nearly) requires a bit too much luck for my
taste.

Moreover, reliable automated bindings with a nice api won't be
available before some time. There are too many discrepancies in the
namings for this to be possible and the annotations are often missing
(absolutely required for out-parameters).

That said, I really prefer having ocaml-gir generate bindings which
are then redistributed as source (and could maybe be distributed along
lablgtk2) rather than distributing ocaml-gir and letting it generate
bindings on each computer. It really needs someone to check everything
went ok.
As for making interfaces for different (read older) versions, I can do
it myself if needed.

Among the reasons I don't believe gobject-introspection is good: the
goal is to create the bindings on each computer but how does the
application maker know which function he can rely on? It's one more
way to fail at runtime, I'd rather avoid that and let the
python/perl/ruby/javascript/... fanboys solve one more problem [NB:
I've been deeply annoyed at how pythonic the .gir/.xml files felt).

 ---

Adrien Nader