[Geany-Devel] Let's use Vala

[Matthew Brush]

On 13-11-10 06:25 AM, Thomas Martitz wrote:
> Am 10.11.2013 05:44, schrieb Matthew Brush:
>> 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. The pros and cons likely will be slightly biased since I would
>> obviously like to use Vala in Geany, but here they are anyway:
>
>
> I'm undecided: on the one hand I would love if we could use Vala for new
> Gobject-related and OOP code, but on the other hand Geany is full of
> non-gobject code and Vala is still young, not widespread and
> un-standardized.
>

The idea is exactly that; to use it for new/re-factored code, which as 
its re-factored would become nice maintainable, bindable (for plugins) 
GObject-style code[1]. Agree it's still young, but as long as it's not 
just going to vanish[2], it's hard to avoid this with any non-C/C++ 
language (ex. you could make the same argument against D or Go or any 
other not really old technology, it's almost a self-fulfilling prophecy 
when approached like that).

> I'm not against going the Vala route but I guess my uncertainty counts
> as a no.
>
> Perhaps we should first make it easier to write plugins in Vala (heck,
> merge some bindings already) and see how it plays out.
>

Any parts of core that are written in Vala would be automatically 
bindable to plugins (assuming some re-working of the plugin-related code 
and such), thus reducing the stuff in the manually maintained and 
already somewhat out of date .vapi file.

Cheers,
Matthew Brush

[1]: And to be clear, Geany also does have some GObject-style code, we 
have several GObjects already, we use a toolkit based on GObject and 
IIRC Enrico even said before that had he known GObject better at the 
time, Geany code would be having lots more of the same.

[2]: And if it did vanish, since it's using the same framework we 
already use, it could trivially (and boringly) be ported 1:1 back to C code.