[Geany-Devel] Let's use Vala

Matthew Brush mbrush at xxxxx
Sun Nov 10 19:27:21 UTC 2013


On 13-11-10 07:40 AM, Colomban Wendling wrote:
> Le 10/11/2013 05:44, Matthew Brush a écrit :
>> Hi all,
>>
>> In the spirit of the previous discussions about using C99 and C++ in
>> Geany code with similar subject lines, I'd like to take a
>> poll/discussion for allowing the use of Vala for new/re-written Geany
>> code. [...]
>
> Well… it's a little complicated.  I agree that features from a
> higher-level language could help, it being C++, Vala or something.  It's
> definitely shorter to write some things in those languages than in C,
> and memory management is definitely easier.  I see one advantage in Vala
> over C++: that it actually is C ([1]), just like our current code.
>
> I agree that Vala would help if we want to port the code to something
> more OOP-style -- since obviously the language supports it by itself.  I
> agree it's probably a good idea.  But the port won't happen magically.
>

Agreed, but one of the reasons I created this thread is to get agreement 
that we *can* use Vala and then when we do any refactoring, it makes it 
that much easier. I'm sure you already know I'm bringing this topic up 
because I'm willing to do a lot of the work :)

> The problem I see is that using C from Vala requires a more or less
> manual interfacing, even if quite easy to write.  This adds actual
> complexity.  We could try by porting leaf modules to Vala and see (maybe
> utils?) -- since calling Vala API from C is native --, but it's probably
> not the modules that would benefit the most from the language.
>

This was my same thought. There are lots of "modules" in Geany that 
could benefit from re-factorings, but even starting with some of the low 
hanging fruit like utils, uiutils, any of the existing GObjects, 
including geanyobject.c which as a demo, I converted to Vala reducing 
the lines of code count from around 400+ to around 40:

Before:
https://gist.github.com/codebrainz/7274867

After:
https://gist.github.com/codebrainz/7274865

And the C code that uses it needn't even change one bit in this case.

> To sum up, my point is that having more than one language might add too
> much of a glue layer for it not to weight down the idea.
>

It really depends how it's done. The type of refactorings I'm 
envisioning (and obviously volunteering to do) wouldn't require much 
glue as they would clean up individual modules(files) leaving the 
outside world more or less the same (aside from tweaking the existing C 
code for slightly different calling conventions/parameters or whatever).

> Sorry Matthew, but it's kind of an "I like Vala but I don't know" :)
>

Basically what I'm asking is; if someone volunteered to cleanup a bunch 
of the code, make it automatically bindable for plugins, much easier to 
maintain/read, and did it without adding a bunch of glue (which you 
actually already wrote a bunch of :), would they be wasting their time 
and have it blocked just because it's not C, or can we get a basic 
agreement, in principle, that in this case, we would be open to allowing 
some Vala in new/re-factored code?

>> * Actively developed so sometimes we probably have to require specific
>> valac versions to support certain features (ie. nothing like c89, c99,
>> c++98, etc but not unlike supporting newer G* versions).
>
> Not to mention bugfixes in bindings, that are much less frequent today
> but weren't rare a dozen months ago or something.
>

Indeed, although if we did hit some bugs in the bindings (as you said 
less and less likely as Vala progresses), it's quite easy to fix them 
and contribute the patch upstream like we do with CTags and Scintilla.

>> * As with above, may require to use fairly modern/specific dependency
>> versions of the G* C libraries (ex. might not work on RHEL or some other
>> LTS distros).
>
> I think Vala supports targeting a particular GLib version for what it
> itself generates (vs. what API you explicitly use in your own code), so
> it may not be an issue.  And I think e.g. GTK is just a lib to Vala's
> eyes, so you just have to use the part of it that match your preferred
> version, just like we already do.
>

That's good to know, should be taken off the "cons" list and moved to 
the "pros" list then :) And yes GTK is just another lib, any of the 
stuff in the .vapi binding that isn't used from Vala won't be put into 
the generated C code, so you're right about that too.

>
>
> [1] so allows to keep full C compatibility without only using an
> uninteresting subset of the language, unlike the C++ discussion
> suggested, which was basically "use C++ but nothing in headers that's
> not C compatible, so excluding classes, and much of the interesting
> stuff in C++".

In addition, you literally *can't* mix Vala and C code in the same file, 
so there's no weirdness about exceptions, GTypes vs C++/stdlib types, 
and confusion about which language is being used in a given function.

Cheers,
Matthew Brush


More information about the Devel mailing list