hi Zeeshan; On 23 January 2012 02:14, Zeeshan Ali (Khattak) <[email protected]> wrote: > On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau <[email protected]> wrote: >> 2012/1/21 Zeeshan Ali (Khattak) <[email protected]>:
>>> There are way >>> too many of the libraries to take care of and on top of that they >>> change all the time. Ideally each library should be providing vala >>> bindings and take care of keeping it up2date. So its really not a >>> fault of vala itself. I don't agree with this assessment. you're just deferring the issue to every library under the sun, and this is very much problematic in a variety of reasons: - as a maintainer, now I'd have to care not only about introspection, but also about a vapi file - which is another redundant format that expresses the library's API; so the first thing I'd look at would be generating the latter in terms of the former, which introduces a build dependency (albeit optional) on Vala. so it's my library that now has to deal with the compiler and generator bugs. yeah, right: not going to happen. - I have used Vala, but I'm not an expert on figuring out its quirks, nor am I using it for my day to day work; this means that I'll have to rely on Vala developers to update the Vala bindings. this means that Vala developers and users will now need to go through various bugzilla products and git repositories to fix the Vala bindings in each and every project that ships one. - not every library is going to get their Vala binding in tree, and not every library is going to get a Vala binding in tree at the same time; in other words: some C libraries simply won't ship Vala bindings (libc anyone? all the crazy little C libraries that do not depend on GLib/GObject but that Vala users are so keen on accessing from something that looks likes a high level language?) and you'll have various cycles between now and the point when the current bindings set is spread into enough projects. there are also the two whole issues of "the introspection format does not allow us to create the same vapi files as hand-writing them" and the "the introspection format does not cover all features of Vala so we cannot write libraries in Vala and have them introspected", which are kind of a red herring. yes, hand-writing is always going to be more expressive because you can "fix" the C API in your binding. well, tough: fix the C API instead. and yes, writing a library in Vala is moderately insane *anyway*, given the amount of build issues that are introduced, and the fact that now Vala has to always create the exact same ABI, even in the case of bugs. >> Well, when people say "vala", they mean what's in vala.git or the vala >> tarball. I agree there is a difference between vala-the-language and >> vala-the-bindings, but since they are shipped as a single entity, vala >> = vala-the-language + vala-the-bindings, it's not really useful to >> consider them separately. My feeling is that shipping the 2 separately >> might help (people may be able to keep using vala-the-language from >> their distro, but some module would require very new vala-the-bindings >> tarballs). Dunno how practical that would be. > > I see your point and agree with your solution but as a plan-B. In case > we encounter heavy resistance against pushing individual bindings to > respective libraries, lets look into this option. no, I'd seriously look into splitting out the bindings repository from the Vala compiler repository *first*, if I were you. and then, if I still were you, I'd seriously look into making Vala and introspection play nice together, so that maintainers and users have to stop caring about this particular issue. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
