Maintainability
While I think maintainability could be improved, adding to history commits from contributions, apart from the ones coming from current Maintainer. Actually, there are some lot of commits not in history coming from authors outside current ones. Hope with new GitLab GNOME’s instance, this will reflect the correct situation.
Behind scenes, Vala has to improve its code base to adapt to new requirements like to develop a descent Vala Language Server and more IEDs supporting Vala. At least for me, even GEdit is productive enough to produce software in Vala, because the language itself; write a Class, an Interface and implement interfaces, is 10 times faster in Vala than in C.
Vala has received lot of improvements in last development cycles, like a new POSIX profile, ABI stability, C Warnings improvements and many other, to be reported in a different article.
Look at Vala’s repository history, you will see more “feature” commits than “bindings” ones, contrary to the situation reported by Emmanuel, while should be a good idea to produce a graphic on this, but resent improvements could tell by them self the situation has been improved in recent release cycles.
Lets look at repository’s chart. It reports 2000 commits in the last 3 months, 1.1 average per day, from 101 contributions as for October 19, 2018. Me at 10 commits from the last year, so I’m far to be a core contributor, but push ABI stability to be a reality. My main contributions are to communicate Vala advances and status.
Vala as a language
Vala has its roots as a GObject oriented language. Currently for C too, because it can produce C code without dependent on GLib/GObject.
Program a C code base using an Object Oriented Programming is easy on Vala, even if the C output are GObject classes or not. You can produce Compact Classes, as for Vala’s Manual:
Compact classes, so called because they use less memory per instance, are the least featured of all class types. They are not registered with the GType system and do not support reference counting, virtual methods, or private fields. They do support unmanaged properties. Such classes are very fast to instantiate but not massively useful except when dealing with existing libraries. They are declared using the Compact attribute on the class
In C a compact class is a simple struct, its fields can have accessors, so your users just call a get/set method to access it and run additional code when is done. Following code:
[vala]
[Compact]
class Caller {
public string _name;
public string name {
get {
return _name;
}
set {
_name = value;
}
}
public void call (string number) {}
}
[/vala]
Is translated to:
#include <glib.h>
#include <glib-object.h>
#include <stdlib.h>
#include <string.h>
typedef struct _Caller Caller;
#define _g_free0(var) (var = (g_free (var), NULL))
struct _Caller {
gchar* _name;
};
void caller_free (Caller * self);
static void caller_instance_init (Caller * self);
void caller_call (Caller* self,
const gchar* number);
Caller* caller_new (void);
const gchar* caller_get_name (Caller* self);
void caller_set_name (Caller* self,
const gchar* value);
void
caller_call (Caller* self,
const gchar* number)
{
g_return_if_fail (self != NULL);
g_return_if_fail (number != NULL);
}
Caller*
caller_new (void)
{
Caller* self;
self = g_slice_new0 (Caller);
caller_instance_init (self);
return self;
}
const gchar*
caller_get_name (Caller* self)
{
const gchar* result;
const gchar* _tmp0_;
g_return_val_if_fail (self != NULL, NULL);
_tmp0_ = self->_name;
result = _tmp0_;
return result;
}
void
caller_set_name (Caller* self,
const gchar* value)
{
gchar* _tmp0_;
g_return_if_fail (self != NULL);
_tmp0_ = g_strdup (value);
_g_free0 (self->_name);
self->_name = _tmp0_;
}
static void
caller_instance_init (Caller * self)
{
}
void
caller_free (Caller * self)
{
_g_free0 (self->_name);
g_slice_free (Caller, self);
}
Could you find some improvements in C code generation?
As you can see, Vala generates code to create your struct, access your fields while run costume code, to free your struct and initialize it. Your C users will have a clean and easy API to use, as you expect, your struct.
If you use Vala to access your C struct, also written in Vala, it will create and free correctly automatically.
So,
Less code, more features.
Vala Pushing up Complex projects
GObject/GInterface are a powerfull tool, but is really hard to use in C if you have to write and implement a complex hierarchy of classes and interfaces. W3C DOM4, is a clear example of it; sure is possible implement in C, but is hundred times easy to implement and maintain in Vala.
GXml and GSVG are an example on how complex a hierarchy can be, and how they have been implemented in a short time.
GXml’s GomElement hierarchy just shows all interfaces it should implement to be DOM4’s Element.
Have you tried to write lot of fragmented featured interfaces in C and implement all of them in a single GObject class?
W3C SVG 1.1 specification have lot of interfaces to write and implement to have a fully compliant object’s class.
Implement GSVG over Vala, makes SVG 1.1 possible in a short time; but don’t stop here, because maintain this complex hierarchy, like move an object from final to derivable one, or move methods from a final to parent class, including its interface implementation, is hundred times easy to do in Vala than in plain C/GObject.
Vala allows: Complex Interface hierarchy implementation easy
While GSVG implementation is not completed, Vala is the right tool to use on this kind of projects.
Vala libraries are Introspectable and usable in other languages
Yes, C GObject classes are introspectable, but lot of annotations are required to produce GIR/TYPELIB, usable in Python or JavaScript.
Vala code produce Introspection Annotations as you write. Produce GIR XML file format is a matter to use --gir switch. Errors and warnings in Vala are focused to make your classes introspectable consistent; for example, you can’t return NULL in Non NULL declared methods.