1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
.. -*- mode: rst -*-
.. -*- coding: utf-8 -*-
Présentation de Vala
####################
:date: 2010-06-11
:tags: Libre, Programmation
J'ai découvert une présentation du langage dans GLMF n°127 qui
l'utilisait pour se brancher sur le pare-feu. Cela ayant aiguisé ma
curiosité, j'ai cherché à en savoir davantage sur le langage. Le langage
C m'a toujours paru difficile à aborder. Non pas au niveau de sa
syntaxe, mais au sujet de l'accès à sa documentation et aux librairies
disponibles. Pour moi qui suis habitué à Java ou à Python, j'ai regardé
Vala comme un moyen de mettre un pied dans le C. Je vais essayer de
présenter ma manière de le voir, après avoir fait une petite plongée
dedans…
Présentation
~~~~~~~~~~~~
Le langage Vala a été créé par les développeurs de Gnome pour qu'ils
puissent disposer d'un langage de haut niveau. Gnome ayant eu pendant
quelque temps un pied (dansant) dans mono, Vala en est très inspiré.
(Je ne connais pas mono et ne peux donc pas lancer de comparatif, je
vous renvoie donc à celui présenté par Gnome `par rapport à
C# <http://live.gnome.org/Vala/QuickIntroForCSharpProgrammers>`_, et
pour `Java <http://live.gnome.org/Vala/ValaForJavaProgrammers>`_). Le
langage est ensuite compilé en C, et GCC est utilisé pour la compilation
d'un exécutable. On est donc dans un langage intermédiaire, qui reste
très proche du C comme nous allons le voir par la suite.
Analyse
~~~~~~~
Langage objet haut niveau Vala est tout d'abord un langage haut niveau :
on y retrouve des *interface* (pour pouvoir moduler le code facilement), des
*delegate* (qui permettent de définir un type de fonction pour un callback),
une gestion *événementielle* (gérer le déclenchement de plusieurs méthodes dans
le code par un appel unique) … On dispose donc d'un langage objet assez riche
pour éviter d'avoir à passer du temps sur des détails et se concentrer sur le
programme et son déroulement. Il est pensé objet et l'on retrouve vite ses
marques, tout comme l'on sent qu'il est assez facile d'« abstraire » le code
pour faire une application qui n'en reste pas un simple script… Je n'ai pas
envie de détailler la syntaxe du langage et tout ce qu'il intègre car vous
pourrez trouver tout cela en ligne. Je vous renvoie au `tutoriel
<http://live.gnome.org/Vala/Tutorial>`_ qui explique la structure du langage en
détail, qui présentent des exemples détaillés. La GLib Le langage est basé sur
la GLib, la librairie standard utilisé dans les applications GTK. La plupart
des types primitifs (int…) sont donc en réalités des types issus de cette
librairie (gint…). On accède ainsi à l'ensemble des méthodes de la GLib,
diffusées sous formes de classes objets et bien documentées (la `valadoc
<http://valadoc.org/index.html>`_). Cela rejoint l'histoire de Vala puisque La
GLib est tout utilisée par les développeurs Gnome (on constate d'ailleurs que
la plupart des composants Gnome ont une entrée dans cette Valadoc). Il ne faut
cependant pas croire que l'on dispose avec cette bibliothèque standard d'un
ensemble de routines aussi riche que dans le package standard d'un Java ou d'un
Python : la GLib est avant tout destinée à des développeurs C, et beaucoup des
méthodes standard du C ne sont pas disponibles. Pour parer cela, Vala propose
une classe POSIX[LIEN] proposant les méthodes standard du C, mais celle-ci
n'est pas exhaustive et il nous arrive souvent de tomber sur une fonction qui
ne nous est pas accessible via le langage haut niveau qu'est Vala. Les Bindings
Pour répondre à cela, propose la possibilité de mettre en place un binding vers
une libraire C de manière native. (Normal me direz-vous, le code en sortie de
Vala est du C !) On peut donc très facilement utiliser n'importe quelle
libraire existante. Vala étant un langage objet, il devient donc possible
d'utiliser les librairies standard au sein d'un code objet de haut niveau. Cela
ne demande que quelques lignes, demandant au minimum le fichier dans lequel se
trouve la définition de la méthode, et sa signature. Exemple du binding
définissant la méthode execl (issue du fichier /usr/share/vala/vapi/posix.vapi) :
::
[CCode (cheader_filename = "unistd.h")]
public int execl (string path, params string[] arg);
et voici la signature de la méthode C correspondante :
::
extern int execl (__const char *__path, __const char *__arg, ...) __THROW __nonnull ((1));
Les types primitifs de la GLib étant basés sur les types primitifs C
correspondants, il n'y a pas de problème de cast dans la plupart de cas.
Toutefois, Vala utilise des char\* pour définir ses string : il est
parfois nécessaire de mettre en place faire un cast quand une méthode
nous un char[] : même dans le code haut niveau, le C n'est jamais loin…
C'est souvent frustrant de devoir mettre en place un binding pour une
fonction disponible en standard dans la libc. Je pense qu'il manque la
possibilité d'inclure directement du code C dans le code vala, tout
comme il est possible directement de l'assembleur dans du C. Cela
permettrait un confort dans l'utilisation qui n'est pas disponible
actuellement. À noter qu'un outil permet de mettre en place ces bindings
pour les composants basés sur GObjet (Gnome toujours…). De plus de
nombreux bindings sont disponibles pour les composants Gnome. Attention,
cela n'empêchera pas d'avoir à installer les headers C correspondants !
Les profils Il est possible d'utiliser des profils de compilation. Cette
option encore expérimentale a été mise en place pour répondre à des
réclamations de la part des utilisateurs qui voulaient programmer en
Vala sans avoir de dépendances envers la GLib. Ainsi, il est possible
d'appeler le compilateur avec la syntaxe suivante :
::
valac --profile posix
ce qui a pour conséquence de réduire le jeu de bibliothèque par défaut à
celles disponibles dans la classe POSIX. Cela permet de limiter les
dépendances du programmes, mais beaucoup de types standard de Vala
deviennent de ce fait indisponible; on sent bien que le langage n'a pas
été pensé pour ça.
Conclusion
~~~~~~~~~~
Pour résumer, je dirais que Vala correspond à ce qu'il annonce : un
langage haut niveau pour faciliter la création d'applications Gnome. Dès
que l'on cherche à sortir de ce cadre, on se retrouve confronté à des
limitations (qui ne sont bien sûr pas insurmontable) :
- Pour ceux qui ne cherche pas à travailler sur du code Gnome,
embarquement de bibliothèques qui ne nous intéressent pas forcément.
(Bien que sur ce point, la GLib est plutôt standard sur les PCs
ayant X d'installés)
- Pour ceux qui cherchent un langage de haut niveau, le C est encore
trop présent entre les lignes pour pouvoir l'oublier complètement.
D'un autre côté, l'intégration du code C n'est pas toujours évidente
puisqu'elle oblige à déclarer des bindings pour des fonctions
standards.
- Mais surtout, le fait que l'ensemble des fonctions de la libc ne
soient pas encore disponibles oblige à mettre le doigt dans les
bindings régulièrement.
Le langage est bien sûr encore amené à évoluer, et les points que je cite ici
ne sont pas pour autant rédhibitoires. D'un point de vue totalement subjectif
Je trouve le langage simple mais sans trop de saveur. Ça reste un langage objet
qui n'est bien sûr pas révolutionnaire; on sent qu'il ne fait que reprendre les
concepts des langages qui l'ont inspiré, mais le produit est cohérent, et
d'après les benchs génère un code plutôt optimisé (en rapport avec le temps que
l'on pourrait passer à produire le même code en C). Après, je ne prends pas le
même plaisir à programmer en Vala qu'en python (j'avais bien dit que j'étais
subjectif ^^). Cela dit, pour moi, qui ne suis pas un développeur Gnome, je
suis plus intéressé par la possibilité d'avoir un langage haut niveau qui reste
très proche du C, avec les performances qui vont avec; si le prix pour cela est
une dépendance vers la GLib, ça reste un coût sommes toutes assez faible.
|
