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
147
148
149
150
151
152
153
|
.. -*- 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 essayé de
présenter ma manière de le voir, après avoir fait une petite plongée
dedans…
Présentation
~~~~~~~~~~~~
Le langage Vala à été créé par les développeurs de Gnome pour qu'ils
puissent disposer d'un langage de haut niveau. Gnome ayant eu pendant
quelques 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 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 n'y 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
correspondant, 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 forcement.
( 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 prend
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.
|
