Pour le C++, c'est un peu plus délicat - en fait, c'est aussi facile qu'en C. C'est à dire facile si la librairie C++ en question a prévu une interface C... sinon, on cherche encore des solutions pour accéder plus facilement aux librairies C++, peut-être du côté de SWIG: [http://www.swig.org/]
Est-il facile d'utiliser une bibliothèque ooc depuis le C
Oui, même si ça fait des noms de fonctions un peu long =) du genre mon_package__MaClasse_maFonction() C'est pour ça que j'aimerais faire un générateur de headers C avec des #define qui permettraient de réduire ça à MaClasse_maFonction(), etc.
Depuis les langages dynamiques tels que python ou ruby?
Quelle est la librairie standard d'ooc? Avez-vous l'ambition de fournir à terme une bibliothèque "batteries included" comme python
C'est en effet un facteur déterminant. Nous avons pas mal travaillé sur notre sdk [http://github.com/nddrylliog/rock/tree/master/custom-sdk] qui contient des classes pour les entrées/sorties, le réseau (sockets, etc.), le temps, différentes collections (ArrayList, LinkedList, Stack, HashMap, etc.), les threads, etc..
Il reste des manques à combler, mais il y a pas mal de librairies sur GitHub par exemple des bindings pour CouchDB, sqlite, mais aussi curl, yajl (pour lire du JSON), curses, OpenGL, SDL, etc.
Comment vous comparez-vous aux autres langages situés sur le même créneau: vala, lissaac, haskell, common lisp?
Celui qui se compare le mieux ici est le Vala, dont la différence fondamentale est que son runtime est largement basé sur la GLib. ooc est donc une solution plus légère (les GObjects sont relativement lourd, tant niveau performance que taille de la dépendance)
Je ne connaissais pas vraiment Lissaac mais il semble que ce soit un langage orienté prototype, c'est à dire qu'au lieu d'avoir une hiérarchie de classes, on peut cloner un objet et lui ajouter des méthodes. Cela semble plus dynamique que de l'ooc - donc forcément, avec un coût à l'exécution =) Mais intéressant tout de même.
Quant à Haskell et CL, ils ont bien plus d'aspects fonctionnels qu'ooc à l'heure actuelle. Nous nous en rapprochons toutefois dernièrement (avec les closures). Les list comprehensions sont également prévues pour bientôt, afin de permettre l'évaluation paresseuse (lazy evaluation).
[^] # Re: Joli
Posté par Amos Wenger . En réponse à la dépêche Le langage ooc auto-hébergé - les nouveautés de rock 0.9.0. Évalué à 10.
En C, oui. Il suffit de déclarer les fonctions C comme 'extern', comme ici par exemple: [http://github.com/nddrylliog/rock/blob/master/custom-sdk/lan(...)]
Pour le C++, c'est un peu plus délicat - en fait, c'est aussi facile qu'en C. C'est à dire facile si la librairie C++ en question a prévu une interface C... sinon, on cherche encore des solutions pour accéder plus facilement aux librairies C++, peut-être du côté de SWIG: [http://www.swig.org/]
Est-il facile d'utiliser une bibliothèque ooc depuis le C
Oui, même si ça fait des noms de fonctions un peu long =) du genre mon_package__MaClasse_maFonction() C'est pour ça que j'aimerais faire un générateur de headers C avec des #define qui permettraient de réduire ça à MaClasse_maFonction(), etc.
Depuis les langages dynamiques tels que python ou ruby?
Python: [http://github.com/fredreichbier/pyooc]
Ruby: à faire =)
Quelle est la librairie standard d'ooc? Avez-vous l'ambition de fournir à terme une bibliothèque "batteries included" comme python
C'est en effet un facteur déterminant. Nous avons pas mal travaillé sur notre sdk [http://github.com/nddrylliog/rock/tree/master/custom-sdk] qui contient des classes pour les entrées/sorties, le réseau (sockets, etc.), le temps, différentes collections (ArrayList, LinkedList, Stack, HashMap, etc.), les threads, etc..
Il reste des manques à combler, mais il y a pas mal de librairies sur GitHub par exemple des bindings pour CouchDB, sqlite, mais aussi curl, yajl (pour lire du JSON), curses, OpenGL, SDL, etc.
Comment vous comparez-vous aux autres langages situés sur le même créneau: vala, lissaac, haskell, common lisp?
Celui qui se compare le mieux ici est le Vala, dont la différence fondamentale est que son runtime est largement basé sur la GLib. ooc est donc une solution plus légère (les GObjects sont relativement lourd, tant niveau performance que taille de la dépendance)
Je ne connaissais pas vraiment Lissaac mais il semble que ce soit un langage orienté prototype, c'est à dire qu'au lieu d'avoir une hiérarchie de classes, on peut cloner un objet et lui ajouter des méthodes. Cela semble plus dynamique que de l'ooc - donc forcément, avec un coût à l'exécution =) Mais intéressant tout de même.
Quant à Haskell et CL, ils ont bien plus d'aspects fonctionnels qu'ooc à l'heure actuelle. Nous nous en rapprochons toutefois dernièrement (avec les closures). Les list comprehensions sont également prévues pour bientôt, afin de permettre l'évaluation paresseuse (lazy evaluation).