jeudi 17 janvier 2013

Modifier un espace de nom sans casser la rétro-compatibilité

À l'origine, l'espace de nom de atoum (non, je ne dirais pas qu'il s'agit d'un framework de tests unitaires simple, moderne et intuitif pour PHP ≥ 5.3, et non, je ne l'ai pas dit, je l'ai écris) devait être tout simplement atoum.

Et puis, un jour, un truc qui s’appelait à l’époque le PHP Working Group a pondu un truc appelé PSR-0, une recommandation visant à favoriser l’interopérabilité entre des projets différents en définissant une norme concernant la nomenclature à utiliser pour nommer à la fois les espaces de nom et les classes PHP, afin de normaliser le mécanisme d’autochargement.

À l’époque, l’idée m’avait paru excellente et comme par nature atoum était destiné à être utilisé dans des projets divers et variés, j’ai décidé de suivre la recommandation PSR-0 et de modifier son espace de nom en mageekguy\atoum afin de suivre le modèle vendor\project.

À l’époque, cela avait été facile, car le nombre de fichiers composant le projet était relativement modeste, et de plus, je n’avais pas à assurer une quelconque rétrocompatibilité puisque j’étais son seul utilisateur.

La modification a donc été simple et rapide et atoum a été rendu public avec cet espace de nom et il a commencé à être utilisé par de plus en plus de personnes et aussi bien dans un cadre personnel que professionnel.

Et j’ai alors commencé à avoir des remarques concernant son espace de nom et plus précisément à propos du fait qu’il était un peu trop lié à ma personne, et qu’en conséquence, ça ne faisait pas très sérieux, ou du moins pas suffisamment pour favoriser l’utilisation du projet en entreprise.

Sur le moment, je n’y ai pas accordé d’importance et j’ai alors subit un lobbying suffisamment puissant pour que lors de ma conférence au dernier Forum PHP, je demande à mon public de choisir entre mageekguy\atoum et atoum\.

Et le public a choisi atoum\.

Lire la suite

mardi 19 juin 2012

À propos de PSR-0, PSR-1 et PSR-2

Depuis quelques mois, les recommandations du PHP Framework Interoperability Group, ex PHP Working Group, ont beaucoup gagné en visibilité dans le monde des développeurs PHP grâce notamment à la mise en œuvre de la PSR-0 par composer et au travail de Fabien Potencier.

Pour rappel, PSR-0 a pour but d'éviter la mise en œuvre de plusieurs mécanismes d'auto-chargement de classe lorsque l'on utilise des composants provenant de projets différents.

Pour cela, elle définie un certain nombre de règles concernant à la fois le nom des fichiers, leur contenu ainsi que leur organisation.

Cette recommandation a maintenant plusieurs années, mais elle était restée confidentielle jusqu'à ce que composer la démocratise et elle fait maintenant pratiquement partie du vocabulaire courant des développeurs PHP, à tel point qu'elle a été l'un des principaux sujets de discussion au cours du dernier forum PHP, aussi bien parmi les conférenciers que parmi les visiteurs.

Fort de ce succès, le PHP Framework Interoperability Group a donc poursuivi ses travaux et a rédigé les recommandations PSR-1 et PSR-2, qui sont, de mon point de vue et à contrario, de la merde !

Lire la suite

mardi 25 octobre 2011

interfaces == interopérabilité ?

Depuis maintenant pas mal de temps, Lukas Kahwe Smith milite, notamment via twitter, pour que PHP dispose d'un ensemble d'interfaces concernant les besoins de base que l'on retrouve dans la majorité des projets utilisant le langage afin de faciliter l'interopérabilité.

Il y a quelques jours, il est passé à la vitesse supérieure en publiant sur son blog un billet sur le sujet qui a suscité un certain nombre de réactions au sein de la communauté des développeurs PHP.

Il y explique que le fait de disposer de telles interfaces permettrait d'intégrer plus facilement au sein du project X les composants qui lui manque en les empruntant au projet Y.

Lire la suite