Le typage fort des arguments et des méthodes et une bonne chose, ça rend le code plus robuste et plus prévisible.
Le système des behaviors est une bonne chose, ça rend le code plus extensible.
Sauf que le second se marie mal avec le premier, parce que les signatures des fonctions de rappel des behaviors est inconnue — par construction — et donc impossible à contrôler.
On comprends qu’à l’époque de leur mise en place, le typage fort n’était franchement pas à l’ordre du jour, parce que PHP ne le permettait pas vraiment et, ou, c’était plus facile de laisser PHP se charger des conversions de type.
Je me dis qu’il ne serait pas idiot, pour une version future de Dotclear, de pouvoir préciser la signature1 des fonctions de rappel, ce qui pourrait permettre de mettre en place une vérification dynamique d’icelles, voire statique si je trouve un moyen de faire ça…
Pourquoi je cause de ça ? Eh bien essentiellement parce que c’est une des causes des erreurs 500 qu’on va observer avec la future 2.24 et les plugins/thèmes tiers pas mis à jour…
D’ailleurs il faut que je code un plugin à la sauce 2.23, qui plante façon erreur 500, pour tester les solutions de repli que je peux mettre en place !
-
Il s’agit du type du retour de la méthode et du nombre et du type de chacun des arguments d’icelle. ↩︎
1 De Nicolas -
Ce qui rend complexe le typage des fonctions de rappel est qu’on autorise des fonctions trop génériques. Comme tu le dis, la signature est inconnue et donc difficile voire impossible à contrôler.
Une solution pourrait être pour chaque behavior de n’avoir qu’un seul argument qui serait l’objet que l’on veut contrôler/surveiller/altérer/…
Par exemple si je prend le premier Behavior de ta liste, je crois qu’on donne trop de responsabilité à la méthode dcAntiSpam::trainFilters. Elle ne devrait recevoir que le commentaire courant. Pas sûr qu’elle devrait recevoir un cursor ni un dcRecord. Quand je dis que ça n’est pas de sa responsabilité, je veux dire que cette classe qui cherche à savoir si le commentaire courant doit être marqué comme spam ne devrait pas elle même s’occuper de la mise à jour en base de cette information. Peut-être qu’elle devrait elle-même déclencher un behavior interne au plugin pour mettre à jour l’info par exemple.
p.s: le lieu n’est peut-être pas le plus approprié pour en causer !
2 De Franck -
Oui je suis d’accord avec toi, il y a pas mal à revoir question responsabilités des méthodes :-)