Journal Gobject Introspection, Parrot, Mono, JVM etc.

Posté par  (site web personnel) .
Étiquettes : aucune
11
19
juin
2010
Gobject introspection permet d'éviter l'écriture des liaisons entre les bibliothèques C qui utilisent gobject et les autres langages.

En d'autres termes, le support de gobject introspection par telle implémentation de Javascript, de Python, de Scheme, de Lua, de brainfuck... vous ouvre la porte sans trop d'efforts à une belle tripotée de bibliothèques C.

L'une des fonctionnalités très appréciée des VM "modernes" c'est la possibilité d'utiliser un framework avec plusieurs langages. C'est l'un des objectifs principaux de Parrot, c'est une fonctionnalité populaire de .NET (ironpython, F# etc.), et c'est arrivé assez tardivement sur la JVM, tardivement mais sûrement (Scala, Clojure etc.).

Gobject Introspection n'est-il pas une "réponse" élégante aux tendances actuelles des VM ?

Avantages, inconvénients ?

Le novice que je suis est très impatient d'entendre vos avis éclairés sur la question !

  • # j'ai pas bien compris comment ca marche

    Posté par  . Évalué à 6.

    avant j'avais

    Mon langage (ruby, python, javascript, ...) et je faisais des liens vers les bibliotheques dont j'avais besoin

    Aujourd'hui, j'ai
    Mon langage (ruby, python, javascript, ...) et je fais un lien Gobject au lieu de la bibliotheque ?


    ou c'est l'inverse,
    si j'ecrit un programme C avec Gobject, je n'ai plus besoin de faire de wrapper/bibliotheque pour les langages Javascript/Ruby/python/... ?

    • [^] # Re: j'ai pas bien compris comment ca marche

      Posté par  . Évalué à 9.

      Un exemple de l'utilisation de GI avec Vala pour créer des bindings (bibliothèques de liaison ?).

      http://live.gnome.org/Vala/Bindings

      La partie la plus importante : « The .gi file defines the objects, structures, constants, enumerations and functions in an abstract markup language. Since GLib and GObject follow a well-defined naming convention for object members, functions, etc., it's possible to generate these independent definitions from the source code. The resulting .gi file is then used to generate the .vapi file that defines the vala bindings. ».

      En gros, grâce à GI, on se retrouve avec une définition précise des fonctions de la bibliothèque qu'on veut « binder ». Il suffit alors de la passer dans un outil adapté au langage qu'on utilise pour créer automatiquement le code kivapreskbien(tm).

      The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

  • # Petite introspection sur l'introspection

    Posté par  . Évalué à 6.

    L'introspection, c'est bien, car ca facilite le boulot des devs pour maintenir a jour leur bindings. Mais ca a un gros default, ca consomme plus de RAM et plus de CPU. Et ce n'est pas marginale, donc ne pas l'oublier quand on utilise ces solutions...

  • # En C++, sans GObject

    Posté par  (site web personnel) . Évalué à 1.

    Une dépêche sur CAMP a été publiée il y a quelques jours :
    http://linuxfr.org/2010/06/15/26993.html

    Pour simplifier, ça permet (permettra...) de faire la même chose, mais en C++ et sans GObject.

    (Je me permet de poster le lien parce que ça peut intéresser les lecteurs de ce journal qui n'ont pas vu passer la dépêche sur CAMP)

    • [^] # Re: En C++, sans GObject

      Posté par  . Évalué à 2.

      Je crois que l'un des intérêts de Gobject Introspection c'est de facilité le liens entre lib C et langages de plus haut niveau. L'intérêt est moins important en C++ parce qu'il existe tout simplement moins de bibliothèque en C++ qu'en C (c'est un état de fait ça ne remet pas en cause la qualité du C++ qui est un langage que j'apprécie énormément (surtout par rapport au C)).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: En C++, sans GObject

        Posté par  . Évalué à 1.

        Mais ces libs ne doivent-elles pas être codées en C+Gobject et pas seulement en C pur?
        Dans ce cas ça réduit beaucoup le nombre de libs accessibles par ce moyen (Gnome en gros).

        • [^] # Re: En C++, sans GObject

          Posté par  (site web personnel) . Évalué à 2.

          Plus précisément, si j'ai bien compris : C+Glib.

          Glib est une bibliothèque multiplateforme utilisée très largement en dehors du monde Gnome il me semble.

          Il faut également rappeler que Gobject Introspection, s'il est un moyen conçu pour fonctionner partout, et avant tout un projet Gnome ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.