From 66a5a0cdccd464930a232c87f91e1b0805f255a5 Mon Sep 17 00:00:00 2001 From: Chimrod Date: Tue, 16 Apr 2013 21:27:30 +0200 Subject: initial commit --- content/Informatique/vala.rst | 153 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+) create mode 100755 content/Informatique/vala.rst (limited to 'content/Informatique/vala.rst') diff --git a/content/Informatique/vala.rst b/content/Informatique/vala.rst new file mode 100755 index 0000000..7ca8e8e --- /dev/null +++ b/content/Informatique/vala.rst @@ -0,0 +1,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# `_, et +pour `Java `_ ). 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 `_ 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 `_ ). 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. -- cgit v1.2.3