diff options
Diffstat (limited to 'content/Informatique/vala.rst')
| -rw-r--r-- | content/Informatique/vala.rst | 165 |
1 files changed, 0 insertions, 165 deletions
diff --git a/content/Informatique/vala.rst b/content/Informatique/vala.rst deleted file mode 100644 index 05aeeb7..0000000 --- a/content/Informatique/vala.rst +++ /dev/null @@ -1,165 +0,0 @@ -.. -*- mode: rst -*- -.. -*- coding: utf-8 -*- - -Présentation de Vala -#################### - -:date: 2010-06-11 -:tags: Libre, Programmation - -.. default-role:: literal - -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 : - -.. code-block:: console - - $ 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. |