API, librairies et spip 5
L'objectif de spip 5 est d'intégrer la "logique composer" dans spip et de migrer du code natif spip vers des librairies composer réputées maintenues, enfin pour le moment. Si l'objectif est louable pour diminuer l'effort de maintenance, je trouve qu'il serait dommage de rater le coche pour robustifier, diffuser, harmoniser, améliorer les API spip.
Déjà en premier lieu, les API de spip ne sont pas clairement détourées ni documentées. Alors oui il y a programmer.spip qui en parle, oui on a parfois le tag phpdoc @api mais rien n'est systématique ce qui fait que beaucoup de plugins utilisent l'api spip qu'ils devinent et donc parfois tombent à coté de la plaque comme moi avec extraire_trads()
qui est devenue une fonction privée en spip 5.
Donc je trouve qu'un recensement des apis d'un coté et des fonctions "hors api" utilisées en dehors de spip dans les plugins serait nécessaire.
Ensuite, une deuxième étape pourrait être de se demander si des fonctions "hors api" ne devraient pas être exposées dans l'api spip finalement.
Enfin pour brancher des librairies externes on aurait une spécification claire de l'api à exposer et de ce qu'on attend fonctionnellement. Et si on doit changer l'api alors on peut immédiatement savoir ce qui sera à modifier et donc les impacts sur les plugins.
De cette façon aussi on se protège des évolutions voire des abandons des librairies externes qui ne manqueront pas de subir des soubresauts à l'instar de tout développement au long court. Je pense bien que l'idée est là mais ma proposition est plutôt de la documenter clairement afin d'en faire une spécification et aussi un manuel d'utilisation.