Discussion :

[Yogui]

Salut

Voici un message qui vient de circuler sur les listes internes de ZF, en prévision de la version 2.0 du framework :

This seems like a perennial issue for me, but I'm bringing it up again because I think it's worthwhile.

Since the beginning of this project, there hasn't really been much in the way of direction given on naming standards for classes in Zend Framework. This lack of consistency is what has yielded two nomenclatures for CLI components ("Zend_Console" vs. "Zend_Controller_Response_Cli"), differing terms for similar concepts ("Zend_Json_Decoder" vs. "Zend_Mime_Decode"), both nouns and verbs in equal measure ("Zend_Loader" but not "Zend_Translator"; alternately, "Zend_Translate" but not "Zend_Load"), and so on.

I first brought this issue up in February 2007 and concluded, "Consistency means predictability, which means being able to recall names without having to check the manual every time. It's why most people can't use PHP's date or string functions without looking at the documentation, for example."

There was a lot of agreement from the community (and a couple Zenders) but no movement because the framework was preparing for 1.0. At the time I was told, "There is life after 0.9.0," and so as we prepare for 2.0, I think it's the perfect time to revisit this.


-Matt

L'idée est de reprendre les composants actuels, d'établir des règles plus strictes pour le développement de nouveaux composants (ainsi que des méthodes dans ces composants), voire de modifier les composants actuels pour homogénéiser le framework.
Comme le dit Matt, pourquoi avons-nous Zend_Translate et Zend_Loader ? L'un est un verbe, l'autre un nom commun.

De nombreux avis favorables ont déjà été transmis, et nous pouvons sans doute nous attendre à une proposition imminente : http://framework.zend.com/wiki/display/ZFPROP/Home
À surveiller donc...

Avez-vous des opinions à ce sujet ?

[SphynXz]

Consistency means predictability, which means being able to recall names without having to check the manual every time

pour moi c'est là tout mon avis. la cohérence du fw en sera bien meilleur... La meilleure autocomplétion c'est celle de nôtre cerveau

[GrandFather]

Bah, s'il ne s'agit que de renommer les classes pour rendre l'ensemble plus cohérent et homogène, c'est parfait... D'autant qu'avec un EDI proposant des possibilités de refactoring automatique, la mise en conformité d'une appli avec ZF 2 ne posera pas beaucoup de difficultés.

S'il s'agit par contre de modifications fonctionnelles et d'interface (API), là c'est plus génant... En prévision d'une telle éventualité, mes applications sont chacune livrées avec le framework complet. Ainsi, les changements induits par la version 2.0 n'aurant de répercussion que sur les applications à venir, pas celles déjà en production.

[Janitrix]

De même je pense que ça reste bénéfique, même si quelques changements doivent être effectués. Mais cela reste trivial, comme précisé par GrandFather, un EDI gère très bien ce genre de renommage et le développeur n'aura donc que peu de soucis.

C'est une bonne idée

[Yogui]

Pour info, le débat sur les listes de ZF est plutôt binaire : soit les gens sont partants car ils comprennent le besoin, soit ils ne voient que les problèmes de compatibilité 1.x/2.x et ne veulent pas accepter que la compatibilité ne soit pas conservée.

Comme cela a déjà été rappelé plusieurs fois sur ladite liste, je me permets de répéter de nouveau que de telles modifications dans une version majeure sont parfaitement acceptables.

• Version mineure : pas de nouvelle incompatibilité (sauf cas extrême et justifié) ;
• Version majeure : de nouvelles incompatibilités sont envisageables.

ZF 2.0 n'est pas prévu pour tout de suite, il reste du temps pour prévoir la migration.

[GrandFather]

Pour info, le débat sur les listes de ZF est plutôt binaire : soit les gens sont partants car ils comprennent le besoin, soit ils ne voient que les problèmes de compatibilité 1.x/2.x et ne veulent pas accepter que la compatibilité ne soit pas conservée.

Tout dépend de l'utilisation qu'on fait du framework et de la nature et de l'étendue de ces incompatibilités. L'impact sera différent selon qu'on est en cours d'évaluation du framework ou si on l'a déjà mis en oeuvre dans des applications en production. Et dans le deuxième cas, si ce n'est que quelques classes/fonctions/paramêtres à modifier, ça n'aura évidemment pas la même incidence que l'abandon de l'URL Rewriting, par exemple.

Dans un contexte professionnel on s'engage généralement sur longtemps avec un Framework, et la stabilité est de fait préférée à la richesse fonctionnelle.

Si les incompatibilités sont vraiment importantes, il reste aussi la possibilité du fork en maintenant et en faisant évoluer les deux branches séparément.