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