Re: Un topo sur Composer

Hello tout le monde

> Le 3 avr. 2018 à 18:27, klaus++ <[email protected]> a écrit :
> 
> J'aimerais connaître aussi l'avis d'ESJ qui a beaucoup contribué à SPIP
> dans le sens d'une "normalisation" de SPIP et de la syntaxe se son
> langage de boucles. En même temps il est assez critique envers la
> programmation objet qui d'après lui n'apporte pas grand chose par
> rapport à un code bien structuré. ...

Y aurait tellement à dire, que ça va être difficile de faire court.

Pour ce qui est de la programmation dite « objet », 
un des problèmes qu’elle entend résoudre est le nommage et la visibilité
des fonctions calculées, qu’elle appelle « méthode «  et qu’elle organise
par des systèmes d’héritage sur lesquels personne n’est d’accord (cf entre autres les versions de PHP).
SPIP tourne autour du même sujet avec les fonctions surchargeables et les pipelines.
Faut-il les abandonner et se plier au modèlé dominant ? Sur le plan de la respectabilité sans doute,
sur le plan de l’efficacité du développement peut-être, mais ce n’est pas sûr.

Sur la question de la normalisaion du code, les méthodes sous-jacentes pour la mesure sont critiquables car trop limitées à de l’analyse syntaxique 
(exemple typique: eval(X) serait une horreur, mais fwrite(X,f);include(f) rien à dire alors que ça fait la même chose).
Toutefois l’aspect respectabilité prend malheureusement de plus en plus d’importance
(c’est comme les agences de notation financières: méthodologie pas fiable, mais pouvoir de nuisance certain)
et il faut reconnaître que 
1. pour des langages sans déclaration de type comme PHP et JS, des outils proches de ce que fournit un compilateur n’est pas du luxe;
2. les outils en question font quand même aujourd’hui un peu plus que de l’analyse syntaxique comme il y a 10 ans.

Au labo on a installé Sonarqube (https://www.sonarsource.com/) et c’est tout de même pas mal.
Un des avantages est qu’il n’est pas limité à un langage: on peut lui filer tout SPIP et il va dénoncer ce qui lui paraît suspect partout:
PHP, JS, CSS, XML (la déclaration de plugin) et HTML mais justement là il hurle à tort à cause de la syntaxe hors norme des squelettes.
Cela dit, et c’est aussi un autre de ses avantages, on peut éditer très finement les règles qu’il utilise pour ne plus voir
des messages qu’on sait non significatifs. 

Cet aspect multi-langage me semble vraiment important dans le cas de SPIP, car la part de JS n’a cessé de grandir face à la part PHP,
et j’ai longtemps rêvé qu’on remplace le code PHP de SPIP par un module Apache, écrit dans n’importe quel langage, et ne traitant plus
que le trio JS/HTML/CSS. Composer, qui a démarré la discussion, est un outil de distribution intéressant et dont les liens avec PHP ne sont pas
déterminants en eux-mêmes (il aurait pu être écrit en autre chose si j’ai bien compris), ça me paraît un bon plan,
en revanche utiliser PHP-fig enverrait à mon avis une image de SPIP trop enracinée dans une unique langage et pour un gain que je ne vois pas 
(ce la dit ma vue baisse). Mais il faut s’interroger sur l’avenir de PHP ? Perl, dont il est issu, est en train de mourir, qui sait s’il ne prendra pas le même chemin.

Mais ce n’est l’avis que d’un utilisateur de SPIP2.

esj

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip