PHPBoost CMS

1. Au début du passage en objet, on a pas franchement tranché et le développement s'est fait petit à petit selon les gouts de chacun.
Depuis on a décidé : sauf cas particulier, on doit toujours faire des singletons, même si pour l'instant ça ne se voit pas encore franchement (on n'a pas fini de tout reprendre). La raison est simple : dans les tests unitaires, on ne peut pas changer le comportement si on passe par des méthodes statiques, alors que si il s'agit de singletons on peut utiliser de faux objets (mocks) qui permettent de simplifier grandement l'écriture des tests. Si tu veux plus de détails, n'hésite pas à demander.

2. Pour ce qui est de la lettre I devant les interface, je suis contre, et je pense que je ne suis pas le seul. Cette règle est appliquée dans certains projets et pas dans d'autres. Je sais par exemple que le code d'Eclipse (en Java) suit cette convention, et c'est un projet significatif (en réalité la tendance globale est assez mitigée). J'ai également bossé dans une boite où c'était la convention, mais personnellement j'y suis opposé, car une interface est un type comme un autre, et il n'y a pas lieu de le préciser. De plus, avec les IDE d'aujourd'hui, il est très facile de savoir si un type est une interface ou non quand on en a besoin. Voilà mon avis.

3. J'avoue que je n'en vois pas l'intérêt. Par contre j'y vois des inconvénients : quand on écrit une classe, il faut penser à lui mettre l'objet racine comme parent (si elle n'a pas d'autre parent), ça complexifie pas mal l'arbre d'héritage, et puis en terme de performances, ça fait perdre un peu de temps, même si je pense que c'est négligeable.
Si tu y vois des raisons intéressantes, je suis prêt à aborder la question, mais pour l'instant je n'en vois pas l'intérêt.

4. Je ne suis pas sûr de comprendre ce que tu veux dire. Tu peux bien sûr hériter de classes du noyau pour pouvoir leur appliquer un comportement particulier lorsque tu les utilises. Par contre, tu ne peux pas faire en sorte que toute l'application utilise systématiquement ta classe plutôt que celle du noyau (c'est peut-être à ça que tu fais allusion). Ca me semble compliqué à gérer et puis ça pose la problématique de conflits (comment on fait si on a 3 modules qui fournissent la même classe ?). Pour contourner ce problème, on peut envisager de passer par l'extension point provider qui peut justement servir à ça, à condition que l'endroit en question fasse appel à un extension point pour obtenir l'objet dont il a besoin.

Quant à ta proposition de reprendre la contribution, je ne suis pas contre, mais ça sera avec notre framework, en envisageant pourquoi pas des discussions comme tu viens de le faire. Si tu es prêt pour cela, je le suis aussi.

Pour le point 3, tu as un exemple de méthode concernée par une telle généralisation ? Moi je n'en vois pas et pour l'instant on n'est pas tombés sur des cas où ça nous a manqué.
Il y a pas mal de frameworks qui le font, je pense par exemple à Qt (bibliothèque graphique en C++ chez qui tout est QObject). En Java, ça existe aussi et c'est implicite : tout hérite d'Object même si on ne le précise pas. Mais le modèle objet de PHP n'est pas structuré comme cela et les méthodes de Object en Java ne me semblent pas nécessaires en PHP.

@Crowkait
Merci pour la restauration


@ben.popeye

3/ pas d'idée précise maintenant. Cela pourrait venir en trempant dans la nouvelle organisation des classes. C'était en anticipation, au cas ou.



Edité par alain91 Le 26/09/10 à 21h48

swan:


Bon retour dans l'équipe Alain