Re: multiple vala versions in 3.4

[Emmanuele Bassi <ebassi gmail com>]

hi Zeeshan;

On 23 January 2012 02:14, Zeeshan Ali (Khattak) <zeeshanak gnome org> wrote:
> On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau <teuf gnome org> wrote:
>> 2012/1/21 Zeeshan Ali (Khattak) <zeeshanak gnome org>:

>>> 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/