Il y a un truc sur lequel je coince, depuis que j’ai fait sauté la variable $core, c’est le fait que depuis, le passage de cette variable dans les fonctions et méthodes appelées n’est plus requis, et ça fait désordre, je trouve.
Sauf que…
Sauf que changer la « signature » 1 d’une fonction ou d’une méthode fout le dawa dans tout le code existant ! Spécialement via le système de behavior (points d’entrée) présent un peu partout dans Dotclear, système où il était plus que fréquent de fournir dans l’un des paramètres (souvent le premier d’ailleurs ce qui complique encore plus, ou pas finalement) la variable obsolète en question.
Il faudrait éventuellement imposer le passage à PHP 8 et utiliser alors le système des arguments nommés, mais je pense que ça casserait quand même des trucs…
Une autre solution serait de « doubler » les appels avec une forme modernisée des behaviors (probablement en ajoutant un numéro de version dans leur nom, comme pour un changement d’API), mais ça implique pas mal de code en plus du côté des appels avec l’avantage toutefois de permettre une transition en douceur. Exemple :
# --BEHAVIOR-- adminBlogPreferencesForm
dcCore::app()->callBehavior('adminBlogPreferencesForm', dcCore::app(), $blog_settings);
On pourrait passer à ceci :
# --BEHAVIOR-- adminBlogPreferencesForm
dcCore::app()->callBehavior('adminBlogPreferencesForm', dcCore::app(), $blog_settings);
dcCore::app()->callBehavior('adminBlogPreferencesFormV2', $blog_settings);
Libre au code appelé de l’être sur la 1re ou 2e forme, avec ou sans le dcCore::app() qui ne sert à rien.
Avec le risque, dans un futur un peu plus lointain, de changer encore la signature des fonctions appelées et d’ajouter une V3, puis une V4, etc etc…
Bref ce n’est pas simple !
À ce stade, la 2.23 publiée récemment ne casse rien de l’éco-système existant, pas plus d’ailleurs que la 2.24 ne devrait le faire, je pense ; je m’interroge cependant pour la suite…
Si vous avez des idées ou remarques à ce sujet, elles sont bien évidemment les bienvenues !
-
La signature d’une fonction (ou méthode) décrit la liste des paramètres et leur ordre, parfois même leurs types. ↩︎
1 De Da Scritch -
ou alors callNewBehavior , qui insère le paramètre désuet ?
2 De Franck -
Non parce que la signature des fonctions appelées par
callBehavior()n’est pas connue à l’avance (le paramètre $core n’est pas toujours présent ou pas toujours au même endroit dans la liste des arguments) ; il faudrait alors avoir un dictionnaire de toutes les signatures connues et agir en conséquence, pas applicable ici.3 De JcDenis -
Peux de temps pour te répondre mais a vue de nez:
renommer tous les behaviors existant à changer,faire un plugin behaviorLegacy contenant les conversions de tous les anciens vers les nouveauxtrainer ça pendant 50 versions,recommencer à php9, 10, …Ah ben non ça ne marcherait même pas.
Il n’y a pas de solutions miracles à ce stade, le code de Dotclear 2 arrive à ses limites pour php 8.2 et plus. Il fonctionne très bien mais ne peux plus vraiment évoluer sans casse.
M’enfin je trouve cela dommage de continuer à se trainer le core dans les appelles de méthodes alors qu’on en a plus besoin 😊
4 De Franck -
Oui je sais pour Dotclear 2, il y a du vieux code et un éco-système qu’il faut préserver ; pas le choix.
Cela dit, l’idée du plugin proxy n’est pas idiote, j’y pensais pour permettre d’intégrer des patches rapidement, ça peut aussi fonctionner pour les modifs de signature…
Faut que j’y réfléchisse !