Sun a finalement annoncé le passage prochain de son langage Java, en
Open Source.
L'hésitation porte à l'heure actuelle sur le type exact de licence, Sun
voulant garder la main sur le langage.
Quoiqu'il en soit le code de Java sera ouvert.
Cela va t-il sonner le glas pour les techno .NET ?
J'utilise essentiellement les API XML et dans ce domaine il y a des choses en java pour lesquelles il n'y a pas d'équivalent ailleurs, notamment des parseurs validants utilisants les schémas par exemple (quoique, je crois que libxml2 prend du Relax NG, mais le support complet des Schéma W3C n'est pas prévu il me semble). C'est inévitable, java est toujours le langage de la première implémentation avec XML.
Néammoins on peut à peu près tout faire avec Perl, parser le XML, le générer, le valider, le traiter avec des XSLT... avec LibXML, TWIG, SAX et compagnie. Maintenant il est clair que les implémentation de références sont faites avec Java.
-- Je suis riche des biens dont je sais me passer. Louis-Jean-Baptiste Etienne Vigée.
Le Mon, 22 May 2006 13:43:08 +0200, SL a écrit :
J'utilise essentiellement les API XML et dans ce domaine il y a des
choses en java pour lesquelles il n'y a pas d'équivalent ailleurs,
notamment des parseurs validants utilisants les schémas par exemple
(quoique, je crois que libxml2 prend du Relax NG, mais le support
complet des Schéma W3C n'est pas prévu il me semble). C'est
inévitable, java est toujours le langage de la première implémentation
avec XML.
Néammoins on peut à peu près tout faire avec Perl, parser le XML, le
générer, le valider, le traiter avec des XSLT... avec LibXML, TWIG, SAX
et compagnie. Maintenant il est clair que les implémentation de
références sont faites avec Java.
--
Je suis riche des biens dont je sais me passer.
Louis-Jean-Baptiste Etienne Vigée.
J'utilise essentiellement les API XML et dans ce domaine il y a des choses en java pour lesquelles il n'y a pas d'équivalent ailleurs, notamment des parseurs validants utilisants les schémas par exemple (quoique, je crois que libxml2 prend du Relax NG, mais le support complet des Schéma W3C n'est pas prévu il me semble). C'est inévitable, java est toujours le langage de la première implémentation avec XML.
Néammoins on peut à peu près tout faire avec Perl, parser le XML, le générer, le valider, le traiter avec des XSLT... avec LibXML, TWIG, SAX et compagnie. Maintenant il est clair que les implémentation de références sont faites avec Java.
-- Je suis riche des biens dont je sais me passer. Louis-Jean-Baptiste Etienne Vigée.
Nicolas Le Scouarnec
trouvée dans /Learning Java/ de Pat Niemeyer. Ce que je trouve un peu curieux c'est ce "dynamic". Je sais bien que Pat Niemeyer est l'auteur de Beanschell, qui permet d'interpréter du java dans un programme java, mais quand même, c'est peut être un peu exagéré la comparaison avec Lisp, non ?
Ben, un exemple "typique" de dynamique , ca pourrait etre ca (désolé pour les lignes longues). Le but est d'avoir du code générique pour faire des algorithmes génétique. Il faut juste fournir des classes ayant certaines propriétés en parametre et ca marche plutot très bien.
C'est loin d'etre évident en C++. On retrouve la meme facilité avec les RMI (Remote Method Invocation). En C++, le controle dynamique des types n'est pas activé par défaut et est moins "automatique" a mon gout. Par contre, ca a un coup pour les perfs tout ca...
Ici, on a "presque" du second ordre, c'est moins clair qu'en LISP/Scheme/CAML au niveau syntaxe, mais au niveau fonctionnalité, on finit par réussir a faire des choses "similaires" (avec des objets plutot que des fonctions).
/.../
public Ile(String url, Class sel, Class evol, Class ind , int nbpop, int nbheros, int type_init) throws RemoteException {
// On crée quelques objets necéssaires... // (c'est du nico, donc faut pas chercher) Class[] typec = new Class[2]; Object[] paramc =new Object[2]; typec[0]=Random.class; typec[1]=Integer.TYPE; paramc[0]=new Random(); paramc[1]=new Integer(type_init);
// On commence par le facile... heros=new Individu[6]; colons_prets=heros_pretsÞmande_herosúlse; cont=true;
// On va créer la population.... population=dieu.getPopulation(); // Une population déja existante ?
if(population== null){ if(!Individu.class.isAssignableFrom(ind)) throw new InstantiationException("On attend une classe de type individu"); population=new Individu[nbpop*4]; for(int i=0;i<nbpop*4;i++){ population[i]=(Individu)ind.getConstructor(typec).newInstance(paramc); } }else{ // rien a faire, j'ai réussi a choper une population toute faite... }
// Et maintenant, on s'arrache les cheveux... Class[] type = new Class[1]; Object[] param = new Object[1]; param[0]=population; type[0]=population.getClass(); if(!Selection.class.isAssignableFrom(sel)) throw new InstantiationException("On attend une classe de type Selection"); selection = (Selection)sel.getConstructor(type).newInstance(param);
if(!Evolution.class.isAssignableFrom(evol)) throw new InstantiationException("On attend une classe de type Evolution"); evolution = (Evolution)evol.getConstructor(type).newInstance(param);
// On lance l'évolution Thread t=new Thread(this); t.setPriority(Thread.MIN_PRIORITY); // On démarre ce processus t.start(); /.../
-- Nicolas Le Scouarnec
trouvée dans /Learning Java/ de Pat Niemeyer. Ce que je trouve un peu
curieux c'est ce "dynamic". Je sais bien que Pat Niemeyer est l'auteur
de Beanschell, qui permet d'interpréter du java dans un programme
java, mais quand même, c'est peut être un peu exagéré la comparaison
avec Lisp, non ?
Ben, un exemple "typique" de dynamique , ca pourrait etre ca (désolé
pour les lignes longues). Le but est d'avoir du code générique pour
faire des algorithmes génétique. Il faut juste fournir des classes
ayant certaines propriétés en parametre et ca marche plutot très bien.
C'est loin d'etre évident en C++. On retrouve la meme facilité avec les
RMI (Remote Method Invocation). En C++, le controle dynamique des
types n'est pas activé par défaut et est moins "automatique" a mon
gout. Par contre, ca a un coup pour les perfs tout ca...
Ici, on a "presque" du second ordre, c'est moins clair qu'en
LISP/Scheme/CAML au niveau syntaxe, mais au niveau fonctionnalité, on
finit par réussir a faire des choses "similaires" (avec des objets
plutot que des fonctions).
/.../
public Ile(String url, Class sel, Class evol, Class ind , int nbpop, int nbheros, int type_init) throws RemoteException {
// On crée quelques objets necéssaires...
// (c'est du nico, donc faut pas chercher)
Class[] typec = new Class[2];
Object[] paramc =new Object[2];
typec[0]=Random.class;
typec[1]=Integer.TYPE;
paramc[0]=new Random();
paramc[1]=new Integer(type_init);
// On commence par le facile...
heros=new Individu[6];
colons_prets=heros_pretsÞmande_herosúlse;
cont=true;
// On va créer la population....
population=dieu.getPopulation(); // Une population déja existante ?
if(population== null){
if(!Individu.class.isAssignableFrom(ind)) throw new InstantiationException("On attend une classe de type individu");
population=new Individu[nbpop*4];
for(int i=0;i<nbpop*4;i++){
population[i]=(Individu)ind.getConstructor(typec).newInstance(paramc);
}
}else{
// rien a faire, j'ai réussi a choper une population toute faite...
}
// Et maintenant, on s'arrache les cheveux...
Class[] type = new Class[1];
Object[] param = new Object[1];
param[0]=population;
type[0]=population.getClass();
if(!Selection.class.isAssignableFrom(sel)) throw new InstantiationException("On attend une classe de type Selection");
selection = (Selection)sel.getConstructor(type).newInstance(param);
if(!Evolution.class.isAssignableFrom(evol)) throw new InstantiationException("On attend une classe de type Evolution");
evolution = (Evolution)evol.getConstructor(type).newInstance(param);
// On lance l'évolution
Thread t=new Thread(this);
t.setPriority(Thread.MIN_PRIORITY);
// On démarre ce processus
t.start();
/.../
trouvée dans /Learning Java/ de Pat Niemeyer. Ce que je trouve un peu curieux c'est ce "dynamic". Je sais bien que Pat Niemeyer est l'auteur de Beanschell, qui permet d'interpréter du java dans un programme java, mais quand même, c'est peut être un peu exagéré la comparaison avec Lisp, non ?
Ben, un exemple "typique" de dynamique , ca pourrait etre ca (désolé pour les lignes longues). Le but est d'avoir du code générique pour faire des algorithmes génétique. Il faut juste fournir des classes ayant certaines propriétés en parametre et ca marche plutot très bien.
C'est loin d'etre évident en C++. On retrouve la meme facilité avec les RMI (Remote Method Invocation). En C++, le controle dynamique des types n'est pas activé par défaut et est moins "automatique" a mon gout. Par contre, ca a un coup pour les perfs tout ca...
Ici, on a "presque" du second ordre, c'est moins clair qu'en LISP/Scheme/CAML au niveau syntaxe, mais au niveau fonctionnalité, on finit par réussir a faire des choses "similaires" (avec des objets plutot que des fonctions).
/.../
public Ile(String url, Class sel, Class evol, Class ind , int nbpop, int nbheros, int type_init) throws RemoteException {
// On crée quelques objets necéssaires... // (c'est du nico, donc faut pas chercher) Class[] typec = new Class[2]; Object[] paramc =new Object[2]; typec[0]=Random.class; typec[1]=Integer.TYPE; paramc[0]=new Random(); paramc[1]=new Integer(type_init);
// On commence par le facile... heros=new Individu[6]; colons_prets=heros_pretsÞmande_herosúlse; cont=true;
// On va créer la population.... population=dieu.getPopulation(); // Une population déja existante ?
if(population== null){ if(!Individu.class.isAssignableFrom(ind)) throw new InstantiationException("On attend une classe de type individu"); population=new Individu[nbpop*4]; for(int i=0;i<nbpop*4;i++){ population[i]=(Individu)ind.getConstructor(typec).newInstance(paramc); } }else{ // rien a faire, j'ai réussi a choper une population toute faite... }
// Et maintenant, on s'arrache les cheveux... Class[] type = new Class[1]; Object[] param = new Object[1]; param[0]=population; type[0]=population.getClass(); if(!Selection.class.isAssignableFrom(sel)) throw new InstantiationException("On attend une classe de type Selection"); selection = (Selection)sel.getConstructor(type).newInstance(param);
if(!Evolution.class.isAssignableFrom(evol)) throw new InstantiationException("On attend une classe de type Evolution"); evolution = (Evolution)evol.getConstructor(type).newInstance(param);
// On lance l'évolution Thread t=new Thread(this); t.setPriority(Thread.MIN_PRIORITY); // On démarre ce processus t.start(); /.../
-- Nicolas Le Scouarnec
SL
Le Mon, 22 May 2006 13:43:08 +0200, SL a écrit :
J'utilise essentiellement les API XML et dans ce domaine il y a des choses en java pour lesquelles il n'y a pas d'équivalent ailleurs, notamment des parseurs validants utilisants les schémas par exemple (quoique, je crois que libxml2 prend du Relax NG, mais le support complet des Schéma W3C n'est pas prévu il me semble). C'est inévitable, java est toujours le langage de la première implémentation avec XML.
Néammoins on peut à peu près tout faire avec Perl, parser le XML, le générer, le valider, le traiter avec des XSLT... avec LibXML, TWIG, SAX et compagnie. Maintenant il est clair que les implémentation de références sont faites avec Java.
Pour SAX l'implémentation qui a valeur de norme est en java. Mais il y a aussi des api StAX tout simplement sans équivalent ailleurs, comme StAX (représentation en flux et non arborescente, mais avec un flux d'objets et pas un flux de callbacks), dont je ne sais pas si elle va avoir un grand avenir, mais qui est quand même en voix d'intégration dans la JRE. Je ne crois pas qu'il y ait un équivalent en Perl. Idem pour les parseurs validant à partir de schémas. J'imagine que XML:LibXML a accès à la validation en Relax NG de libxml, mais il y a des parseurs validants pour les Schéma W3C ? Peut-être Xerces-P ?
Pour XSLT, il y a de quoi faire du XSLT 2 ? Et pour XQuery ? C'est quand même un sérieux avantage d'être le langage de référence sur lequel sont implémentées en premier les spécifications : ça y donne accès deux ans avant... Une autre raison pour choisir un langage, en plus des API générales et de la syntaxe proprement dite dont on cause dasn le salon d'à côté (j'ai bien l'impression que le critère de la syntaxe est au fond le critère la plus triviale qui soit, bien que ça occupe 90 % des discussions).
Pour les bases de données XML, je crois que sleepycat a une interface en Perl, mais c'est quand même en java qu'il y a vraiment un choix diversifié (eXist, etc.).
Avant je faisais tout ça en Perl, je me suis mis à java uniquement pour cette raison. Quand une application dépend complètement d'une technologie, c'est incontournable. Dans les API perl il y a les grands classiques qui existent depuis 5 ou 6 ans (dont l'essentiel est du XS de Matt Sergeant si je me souviens bien), quelques gargouilles gothiques typiques CPAN (genre Twig), mais l'offre n'a rien à voir. Autre exemple : jaxen, un moteur XPath indépendant du modèle de données. Je lui ai développé une interfaçe avec l'API StAX justement. Tout ça aurait été impossible en Perl.
Le Mon, 22 May 2006 13:43:08 +0200, SL a écrit :
J'utilise essentiellement les API XML et dans ce domaine il y a des
choses en java pour lesquelles il n'y a pas d'équivalent ailleurs,
notamment des parseurs validants utilisants les schémas par exemple
(quoique, je crois que libxml2 prend du Relax NG, mais le support
complet des Schéma W3C n'est pas prévu il me semble). C'est
inévitable, java est toujours le langage de la première
implémentation avec XML.
Néammoins on peut à peu près tout faire avec Perl, parser le XML, le
générer, le valider, le traiter avec des XSLT... avec LibXML, TWIG,
SAX et compagnie. Maintenant il est clair que les implémentation de
références sont faites avec Java.
Pour SAX l'implémentation qui a valeur de norme est en java. Mais il y
a aussi des api StAX tout simplement sans équivalent ailleurs, comme
StAX (représentation en flux et non arborescente, mais avec un flux
d'objets et pas un flux de callbacks), dont je ne sais pas si elle va
avoir un grand avenir, mais qui est quand même en voix d'intégration
dans la JRE. Je ne crois pas qu'il y ait un équivalent en Perl. Idem
pour les parseurs validant à partir de schémas. J'imagine que
XML:LibXML a accès à la validation en Relax NG de libxml, mais il y a
des parseurs validants pour les Schéma W3C ? Peut-être Xerces-P ?
Pour XSLT, il y a de quoi faire du XSLT 2 ? Et pour XQuery ? C'est
quand même un sérieux avantage d'être le langage de référence sur
lequel sont implémentées en premier les spécifications : ça y donne
accès deux ans avant... Une autre raison pour choisir un langage, en
plus des API générales et de la syntaxe proprement dite dont on cause
dasn le salon d'à côté (j'ai bien l'impression que le critère de la
syntaxe est au fond le critère la plus triviale qui soit, bien que ça
occupe 90 % des discussions).
Pour les bases de données XML, je crois que sleepycat a une interface
en Perl, mais c'est quand même en java qu'il y a vraiment un choix
diversifié (eXist, etc.).
Avant je faisais tout ça en Perl, je me suis mis à java uniquement
pour cette raison. Quand une application dépend complètement d'une
technologie, c'est incontournable. Dans les API perl il y a les grands
classiques qui existent depuis 5 ou 6 ans (dont l'essentiel est du XS
de Matt Sergeant si je me souviens bien), quelques gargouilles
gothiques typiques CPAN (genre Twig), mais l'offre n'a rien à
voir. Autre exemple : jaxen, un moteur XPath indépendant du modèle de
données. Je lui ai développé une interfaçe avec l'API StAX
justement. Tout ça aurait été impossible en Perl.
J'utilise essentiellement les API XML et dans ce domaine il y a des choses en java pour lesquelles il n'y a pas d'équivalent ailleurs, notamment des parseurs validants utilisants les schémas par exemple (quoique, je crois que libxml2 prend du Relax NG, mais le support complet des Schéma W3C n'est pas prévu il me semble). C'est inévitable, java est toujours le langage de la première implémentation avec XML.
Néammoins on peut à peu près tout faire avec Perl, parser le XML, le générer, le valider, le traiter avec des XSLT... avec LibXML, TWIG, SAX et compagnie. Maintenant il est clair que les implémentation de références sont faites avec Java.
Pour SAX l'implémentation qui a valeur de norme est en java. Mais il y a aussi des api StAX tout simplement sans équivalent ailleurs, comme StAX (représentation en flux et non arborescente, mais avec un flux d'objets et pas un flux de callbacks), dont je ne sais pas si elle va avoir un grand avenir, mais qui est quand même en voix d'intégration dans la JRE. Je ne crois pas qu'il y ait un équivalent en Perl. Idem pour les parseurs validant à partir de schémas. J'imagine que XML:LibXML a accès à la validation en Relax NG de libxml, mais il y a des parseurs validants pour les Schéma W3C ? Peut-être Xerces-P ?
Pour XSLT, il y a de quoi faire du XSLT 2 ? Et pour XQuery ? C'est quand même un sérieux avantage d'être le langage de référence sur lequel sont implémentées en premier les spécifications : ça y donne accès deux ans avant... Une autre raison pour choisir un langage, en plus des API générales et de la syntaxe proprement dite dont on cause dasn le salon d'à côté (j'ai bien l'impression que le critère de la syntaxe est au fond le critère la plus triviale qui soit, bien que ça occupe 90 % des discussions).
Pour les bases de données XML, je crois que sleepycat a une interface en Perl, mais c'est quand même en java qu'il y a vraiment un choix diversifié (eXist, etc.).
Avant je faisais tout ça en Perl, je me suis mis à java uniquement pour cette raison. Quand une application dépend complètement d'une technologie, c'est incontournable. Dans les API perl il y a les grands classiques qui existent depuis 5 ou 6 ans (dont l'essentiel est du XS de Matt Sergeant si je me souviens bien), quelques gargouilles gothiques typiques CPAN (genre Twig), mais l'offre n'a rien à voir. Autre exemple : jaxen, un moteur XPath indépendant du modèle de données. Je lui ai développé une interfaçe avec l'API StAX justement. Tout ça aurait été impossible en Perl.
Nicolas Centa
Nicolas George <nicolas$ writes:
SL , dans le message , a écrit :
Autre exemple de comparaison avec Lips :
In a strictly statically typed language like C or C++, data types are etched in stone when the source code is compiled. [...] In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages the types of objects and performs necessary type checking while an application is executing. These kinds of languages allow for more complex behavior, and are in many respects more powerful. However, they are also generally slower, less safe, and harder to debug.
Voilà un gus qui, de toute évidence, n'a jamais regardé OCaml de pr ès...
:-)
Nicolas George <nicolas$george@salle-s.org> writes:
SL , dans le message <u7j4ewavn.fsf@nospam.com>, a écrit :
Autre exemple de comparaison avec Lips :
In a strictly statically typed language like C or C++, data types
are etched in stone when the source code is compiled. [...] In
contrast, a dynamic language such as Smalltalk or Lisp has a
runtime system that manages the types of objects and performs
necessary type checking while an application is executing. These
kinds of languages allow for more complex behavior, and are in
many respects more powerful. However, they are also generally
slower, less safe, and harder to debug.
Voilà un gus qui, de toute évidence, n'a jamais regardé OCaml de pr ès...
In a strictly statically typed language like C or C++, data types are etched in stone when the source code is compiled. [...] In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages the types of objects and performs necessary type checking while an application is executing. These kinds of languages allow for more complex behavior, and are in many respects more powerful. However, they are also generally slower, less safe, and harder to debug.
Voilà un gus qui, de toute évidence, n'a jamais regardé OCaml de pr ès...
:-)
Emmanuel Florac
Le Tue, 23 May 2006 01:05:01 +0200, SL a écrit :
Avant je faisais tout ça en Perl, je me suis mis à java uniquement pour cette raison.
Je fais du XML de façon modérée, donc je n'ai en aucun cas besoin de bidules nouveaux et sophistiqués. De fait je ne sais pas trop ce qui se fait...
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Aït Ahmed.
Le Tue, 23 May 2006 01:05:01 +0200, SL a écrit :
Avant je faisais tout ça en Perl, je me suis mis à java uniquement
pour cette raison.
Je fais du XML de façon modérée, donc je n'ai en aucun cas besoin de
bidules nouveaux et sophistiqués. De fait je ne sais pas trop ce qui se
fait...
--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Aït Ahmed.
Avant je faisais tout ça en Perl, je me suis mis à java uniquement pour cette raison.
Je fais du XML de façon modérée, donc je n'ai en aucun cas besoin de bidules nouveaux et sophistiqués. De fait je ne sais pas trop ce qui se fait...
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Aït Ahmed.
Stéphane Zuckerman
On Tue, 23 May 2006, SL wrote:
Pour les bases de données XML, je crois que sleepycat a une interface en Perl, mais c'est quand même en java qu'il y a vraiment un choix diversifié (eXist, etc.).
Si tu parles de l'interface de BDB/XML, oui. Les bibliothèques sont écrites en C++, mais il y a des bindings pour Java et Perl (et d'autres langages aussi).
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
On Tue, 23 May 2006, SL wrote:
Pour les bases de données XML, je crois que sleepycat a une interface
en Perl, mais c'est quand même en java qu'il y a vraiment un choix
diversifié (eXist, etc.).
Si tu parles de l'interface de BDB/XML, oui. Les bibliothèques sont
écrites en C++, mais il y a des bindings pour Java et Perl (et d'autres
langages aussi).
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Pour les bases de données XML, je crois que sleepycat a une interface en Perl, mais c'est quand même en java qu'il y a vraiment un choix diversifié (eXist, etc.).
Si tu parles de l'interface de BDB/XML, oui. Les bibliothèques sont écrites en C++, mais il y a des bindings pour Java et Perl (et d'autres langages aussi).
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
talon
Emmanuel Florac wrote:
Le Tue, 23 May 2006 01:05:01 +0200, SL a écrit :
Avant je faisais tout ça en Perl, je me suis mis à java uniquement pour cette raison.
Je fais du XML de façon modérée, donc je n'ai en aucun cas besoin de bidules nouveaux et sophistiqués. De fait je ne sais pas trop ce qui se fait...
Tu peux avoir une petite idée du zoo qui existe ici: http://xmlbench.sourceforge.net/results/features200402/index.html Du peu que je sais, les parsers les plus modernes sont ceux du projet Apache donc Xerces pour parser le XML et Xalan pour le transformer via xslt. Ces deux là existent en version Java et C++, mais il est possible que la version C++ soit en retard. Ensuite il existe des bindings de la version C++ vers Perl (on les trouve sur Google mais je ne les vois pas sur CPAN) et vers python http://sourceforge.net/projects/pyana/
--
Michel TALON
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Tue, 23 May 2006 01:05:01 +0200, SL a écrit :
Avant je faisais tout ça en Perl, je me suis mis à java uniquement
pour cette raison.
Je fais du XML de façon modérée, donc je n'ai en aucun cas besoin de
bidules nouveaux et sophistiqués. De fait je ne sais pas trop ce qui se
fait...
Tu peux avoir une petite idée du zoo qui existe ici:
http://xmlbench.sourceforge.net/results/features200402/index.html
Du peu que je sais, les parsers les plus modernes sont ceux du projet Apache
donc Xerces pour parser le XML et Xalan pour le transformer via xslt. Ces
deux là existent en version Java et C++, mais il est possible que la version
C++ soit en retard. Ensuite il existe des bindings de la version C++ vers Perl
(on les trouve sur Google mais je ne les vois pas sur CPAN) et vers python
http://sourceforge.net/projects/pyana/
Avant je faisais tout ça en Perl, je me suis mis à java uniquement pour cette raison.
Je fais du XML de façon modérée, donc je n'ai en aucun cas besoin de bidules nouveaux et sophistiqués. De fait je ne sais pas trop ce qui se fait...
Tu peux avoir une petite idée du zoo qui existe ici: http://xmlbench.sourceforge.net/results/features200402/index.html Du peu que je sais, les parsers les plus modernes sont ceux du projet Apache donc Xerces pour parser le XML et Xalan pour le transformer via xslt. Ces deux là existent en version Java et C++, mais il est possible que la version C++ soit en retard. Ensuite il existe des bindings de la version C++ vers Perl (on les trouve sur Google mais je ne les vois pas sur CPAN) et vers python http://sourceforge.net/projects/pyana/
--
Michel TALON
Nicolas Centa
Prodejeu writes:
Ouais c'est marrant, parce que moi c'est exactement l'inverse. Je trouve la syntaxe de Java beaucoup moins verbeuse, que celle des langages qui forcent à séparer les entêtes des corps (de classes, méthodes, fonctions, ...). ;-)
Séparer les définitions d'interfaces et les implémentations reste une bonne pratique pour le programmeur.
Prodejeu <prodejeu@free.fr> writes:
Ouais c'est marrant, parce que moi c'est exactement l'inverse.
Je trouve la syntaxe de Java beaucoup moins verbeuse, que celle des
langages qui forcent à séparer les entêtes des corps (de classes,
méthodes, fonctions, ...). ;-)
Séparer les définitions d'interfaces et les implémentations reste une
bonne pratique pour le programmeur.
Ouais c'est marrant, parce que moi c'est exactement l'inverse. Je trouve la syntaxe de Java beaucoup moins verbeuse, que celle des langages qui forcent à séparer les entêtes des corps (de classes, méthodes, fonctions, ...). ;-)
Séparer les définitions d'interfaces et les implémentations reste une bonne pratique pour le programmeur.
Nicolas Centa
writes:
Je te ferais remarquer que je n'ai pas initié ce sous-thread dans le but de savoir qui a la plus grosse, mais uniquement dans le but de démontrer que ce qui est le plus important dans un langage, ce sont ses APIs et pas sa syntaxe.
Dans ce cas on va creer MyPerl avec tout CPAN dedans en standard autoprocla mé et te forcer à l'utiliser, ou tous ne faire que du C parce que c'est pour ce langage que le plus de bibliothèques sont disponibles.
Ridicule...
seb666fr2@yahoo.fr writes:
Je te ferais remarquer que je n'ai pas initié ce sous-thread dans le
but de
savoir qui a la plus grosse, mais uniquement dans le but de démontrer
que
ce qui est le plus important dans un langage, ce sont ses APIs et pas
sa syntaxe.
Dans ce cas on va creer MyPerl avec tout CPAN dedans en standard autoprocla mé
et te forcer à l'utiliser, ou tous ne faire que du C parce que c'est pour
ce langage que le plus de bibliothèques sont disponibles.
Je te ferais remarquer que je n'ai pas initié ce sous-thread dans le but de savoir qui a la plus grosse, mais uniquement dans le but de démontrer que ce qui est le plus important dans un langage, ce sont ses APIs et pas sa syntaxe.
Dans ce cas on va creer MyPerl avec tout CPAN dedans en standard autoprocla mé et te forcer à l'utiliser, ou tous ne faire que du C parce que c'est pour ce langage que le plus de bibliothèques sont disponibles.
Ridicule...
SL
Emmanuel Florac wrote:
Le Tue, 23 May 2006 01:05:01 +0200, SL a écrit :
Avant je faisais tout ça en Perl, je me suis mis à java uniquement pour cette raison.
Je fais du XML de façon modérée, donc je n'ai en aucun cas besoin de bidules nouveaux et sophistiqués. De fait je ne sais pas trop ce qui se fait...
Tu peux avoir une petite idée du zoo qui existe ici: http://xmlbench.sourceforge.net/results/features200402/index.html Du peu que je sais, les parsers les plus modernes sont ceux du projet Apache donc Xerces pour parser le XML et Xalan pour le transformer via xslt.
Sur le critère de l'implémentation de spécification l'un des plus modernes c'est aussi Saxon 8, puisque c'est le seul à implémenter également XSLT 2 et Xquery. C'est un excellent processeur, très rapide et conforme, c'est curieux qu'il ne soit pas dans ce listing. Il y a pas mal d'autres parseurs et surtout les parseurs ne sont pas les seuls librairies importantes : par exemple, les gestionnaires de catalogue.
Je cherche sur CPAN, je ne trouve qu'un module pour les catalog "John Cowan", ("XML::Catalog"), et des trucs absolument pas documentés dont il est impossible de savoir ce qu'ils font à vue de nez : Biblio::Catalog Biblio::Catalog::XML.
Pour la validation des schéma W3C je trouve bien XML::Validator::Schema mais "This module does not implement the full W3C XML Schema recommendation (http://www.w3.org/XML/Schema), but a useful subset."
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Tue, 23 May 2006 01:05:01 +0200, SL a écrit :
Avant je faisais tout ça en Perl, je me suis mis à java
uniquement pour cette raison.
Je fais du XML de façon modérée, donc je n'ai en aucun cas besoin
de bidules nouveaux et sophistiqués. De fait je ne sais pas trop ce
qui se fait...
Tu peux avoir une petite idée du zoo qui existe ici:
http://xmlbench.sourceforge.net/results/features200402/index.html Du
peu que je sais, les parsers les plus modernes sont ceux du projet
Apache donc Xerces pour parser le XML et Xalan pour le transformer
via xslt.
Sur le critère de l'implémentation de spécification l'un des plus
modernes c'est aussi Saxon 8, puisque c'est le seul à implémenter
également XSLT 2 et Xquery. C'est un excellent processeur, très rapide
et conforme, c'est curieux qu'il ne soit pas dans ce listing. Il y a
pas mal d'autres parseurs et surtout les parseurs ne sont pas les
seuls librairies importantes : par exemple, les gestionnaires de
catalogue.
Je cherche sur CPAN, je ne trouve qu'un module pour les catalog "John
Cowan", ("XML::Catalog"), et des trucs absolument pas documentés dont
il est impossible de savoir ce qu'ils font à vue de nez :
Biblio::Catalog Biblio::Catalog::XML.
Pour la validation des schéma W3C je trouve bien
XML::Validator::Schema mais "This module does not implement the full
W3C XML Schema recommendation (http://www.w3.org/XML/Schema), but a
useful subset."
Avant je faisais tout ça en Perl, je me suis mis à java uniquement pour cette raison.
Je fais du XML de façon modérée, donc je n'ai en aucun cas besoin de bidules nouveaux et sophistiqués. De fait je ne sais pas trop ce qui se fait...
Tu peux avoir une petite idée du zoo qui existe ici: http://xmlbench.sourceforge.net/results/features200402/index.html Du peu que je sais, les parsers les plus modernes sont ceux du projet Apache donc Xerces pour parser le XML et Xalan pour le transformer via xslt.
Sur le critère de l'implémentation de spécification l'un des plus modernes c'est aussi Saxon 8, puisque c'est le seul à implémenter également XSLT 2 et Xquery. C'est un excellent processeur, très rapide et conforme, c'est curieux qu'il ne soit pas dans ce listing. Il y a pas mal d'autres parseurs et surtout les parseurs ne sont pas les seuls librairies importantes : par exemple, les gestionnaires de catalogue.
Je cherche sur CPAN, je ne trouve qu'un module pour les catalog "John Cowan", ("XML::Catalog"), et des trucs absolument pas documentés dont il est impossible de savoir ce qu'ils font à vue de nez : Biblio::Catalog Biblio::Catalog::XML.
Pour la validation des schéma W3C je trouve bien XML::Validator::Schema mais "This module does not implement the full W3C XML Schema recommendation (http://www.w3.org/XML/Schema), but a useful subset."
