Les 4200 lignes de XLST ont été réécrites en 1300 lignes de Python - pour produire le même résultat avec une forte augmentation de la hackabilité.
Alors, faisant actuellement de la génération de code à base de XSLT pour un projet, ce refactoring m'a intrigué : me serais-je trompé d'avoir utilisé un langage déclaratif alors que j'aime pourtant bien Python ? Je suis donc allé voir de plus près.
J'ai pris un exemple de complexité moyenne, mais regardons par exemple le code original en XSLT :
Franchement, la différence de lisibilité et la soi-disant facilité de « hackage » ne sautent pas aux yeux. Certes il faut connaître XSLT pour mieux le « parser » visuellement, et passer outre sa verbosité, qui doit être son plus gros défaut, mais sinon je trouve la matching des balises avec DOM est vraiment horrible à lire. Tellement que ça doit amener des bugs : le getElementsByTagName() ligne 147 me semble faux, le XSLT ne va chercher que les enfants directs. De plus, tous les anciens cas ne sont pas gérés : rien pour un "refdefine" nul (c'est peut-être une hypothèse assumée, mais pas précisée). Et au passage on perd complètement la notion d'espace de nommage pour les tags ! La verbosité de l'API du DOM pour ça vis à vis de XPath ne doit pas y être pour rien...
En parlant d'API, Miklos les mélange d'ailleurs allègrement ; on passe à SAX pour un autre fichier (qui fait encore une fois des hypothèses plus stricte sur les entrées, les "fastoken" hors d'un "model" étant potentiellement traités, de manière erronée) :
Ce qui fait qu'on peut potentiellement avoir des documents qui ne valident pas, vu que ce genre de parser ne permet plus d'assurer la bonne forme du document...
Ah mais en fait, la conversion précédente amène un bug, qui complique le code python encore plus, corrigeons-le :
Voilà les joies de la conversion. Là où la nouvelle de linuxfr se fourvoie par contre — même si ça vient certes du blog de l'auteur, et qu'on ne vérifie pas forcément la véracité de sources aussi proches — c'est que la réduction du code XSLT ne vient pas de la supposée concision de Python pour ce genre de travail, mais juste de simples suppressions de code ! Le code précédent a par exemple simplement été retiré :
Et de même pour un paquet d'autres. Et la réduction du gros paquet de code généré vient principalement parce qu'on a implémenté moins de choses dans la version python que dans la version XSLT.
Bref, je peux très bien comprendre l'argument de la non-popularité de XSLT pour passer à un langage comme Python, mais d'un côté, ça s'apprend très vite (il y a deux semaines, je n'en avait jamais fait), et c'est un langage très adapté quand on tripote du XML, avec toutes les contraintes que ça amène, et toutes les facilités qu'offre un langage fait pour. En tous cas, les réductions en taille de code présentées n'ont rien à voir avec le fait que ça soit du XSLT. Je suppose que Miklos n'aimait pas, et en a profité pour cracher dessus, de manière fallacieuse.
Mangez du XSLT (mais seulement si vous faites du XML, hein, il ne faut pas être maso non plus), c'est bon.
# Nuances sur le nettoyage XSLT
Posté par benoar . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 10.
Alors, faisant actuellement de la génération de code à base de XSLT pour un projet, ce refactoring m'a intrigué : me serais-je trompé d'avoir utilisé un langage déclaratif alors que j'aime pourtant bien Python ? Je suis donc allé voir de plus près.
J'ai pris un exemple de complexité moyenne, mais regardons par exemple le code original en XSLT :
http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml/factoryimpl_ns.xsl?id=21977778168af134e7f72afcc07ff5062324a19d#n183
avec la version convertie en Python :
http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml/factoryimpl_ns.py?id=6c4de449094048465b81abf93139bb5950fa12c9#n128
Franchement, la différence de lisibilité et la soi-disant facilité de « hackage » ne sautent pas aux yeux. Certes il faut connaître XSLT pour mieux le « parser » visuellement, et passer outre sa verbosité, qui doit être son plus gros défaut, mais sinon je trouve la matching des balises avec DOM est vraiment horrible à lire. Tellement que ça doit amener des bugs : le getElementsByTagName() ligne 147 me semble faux, le XSLT ne va chercher que les enfants directs. De plus, tous les anciens cas ne sont pas gérés : rien pour un "refdefine" nul (c'est peut-être une hypothèse assumée, mais pas précisée). Et au passage on perd complètement la notion d'espace de nommage pour les tags ! La verbosité de l'API du DOM pour ça vis à vis de XPath ne doit pas y être pour rien...
En parlant d'API, Miklos les mélange d'ailleurs allègrement ; on passe à SAX pour un autre fichier (qui fait encore une fois des hypothèses plus stricte sur les entrées, les "fastoken" hors d'un "model" étant potentiellement traités, de manière erronée) :
http://cgit.freedesktop.org/libreoffice/core/commit/writerfilter/source/ooxml?id=dd5dfc8e2a0fc3c0307c0a782ae563b79ba8a84e
Ce qui fait qu'on peut potentiellement avoir des documents qui ne valident pas, vu que ce genre de parser ne permet plus d'assurer la bonne forme du document...
Ah mais en fait, la conversion précédente amène un bug, qui complique le code python encore plus, corrigeons-le :
http://cgit.freedesktop.org/libreoffice/core/commit/?id=63cd667ccb35325a973cf4f98c5e1bf9db92b9b4
Voilà les joies de la conversion. Là où la nouvelle de linuxfr se fourvoie par contre — même si ça vient certes du blog de l'auteur, et qu'on ne vérifie pas forcément la véracité de sources aussi proches — c'est que la réduction du code XSLT ne vient pas de la supposée concision de Python pour ce genre de travail, mais juste de simples suppressions de code ! Le code précédent a par exemple simplement été retiré :
http://cgit.freedesktop.org/libreoffice/core/commit/writerfilter/source/ooxml?id=2046fcd907fe8c0217c5cd43be8420859a0ad435
Et de même pour un paquet d'autres. Et la réduction du gros paquet de code généré vient principalement parce qu'on a implémenté moins de choses dans la version python que dans la version XSLT.
Bref, je peux très bien comprendre l'argument de la non-popularité de XSLT pour passer à un langage comme Python, mais d'un côté, ça s'apprend très vite (il y a deux semaines, je n'en avait jamais fait), et c'est un langage très adapté quand on tripote du XML, avec toutes les contraintes que ça amène, et toutes les facilités qu'offre un langage fait pour. En tous cas, les réductions en taille de code présentées n'ont rien à voir avec le fait que ça soit du XSLT. Je suppose que Miklos n'aimait pas, et en a profité pour cracher dessus, de manière fallacieuse.
Mangez du XSLT (mais seulement si vous faites du XML, hein, il ne faut pas être maso non plus), c'est bon.