metagoto's blog

L'arrivée de php 5.3 et son support pour les namespaces, les lambda functions et autres joyeusetés a le mérite de fédérer au sein du PHP Standards Working Group le gratin des lead developers des "grands" frameworks que sont Zend Framework, Symfony, PEAR, Solar, j'en passe et des meilleurs.

De l'interopérabilité Technique

Un des objectifs du Working Group est de s'accorder sur une interopérabilité technique (technical interoperability). De quoi s'agit-il exactement ? Personne ne le sait, c'est pourquoi dans un premier temps tout du moins, les protagonistes se focalisent sur une interopérabilité du mécanisme d'autoloading dans un contexte namespaces-aware.

PSR-0 Final Proposal

Le Working Group a publié le PSR-0 Final Proposal concernant l'autoloading. Ce document décrit les conditions que les auteurs de librairies et frameworks se doivent de respecter en terme de convention de nommage et de hiérarchie de fichiers afin d'assurer cette interopérabilité. Au passage, on notera les conditions sévères qu'il est nécessaire de respecter pour espérer avoir un droit de vote ou même de participation aux débats.

En résumé, la convention est la suivante:

\<Vendor Name>\(<Namespace>\)*<Class Name>

Dans la partie \<Vendor Name>\(<Namespace>\)*, les séparateurs de namespaces seront transformés en DIRECTORY_SEPARATOR. Pour la partie <Class Name>, les underscores seront transformés en DIRECTORY_SEPARATOR. Cette dernière partie est donc backward compatible avec la convention à la Horde / PEAR.

The standards we set here should be the lowest common denominator for painless autoloader interoperability.

Et voici l'implémentation proposée de SplClassLoader

J'affirme que non seulement ce standard est inutile, mais qu'en plus il pose plus de problèmes qu'il n'en résoud.

Larry Garfield de Drupal ou Robert Lemke de TYPO3/FLOW3, tous deux membres du Working Group, expriment leur inquiétudes quant à la possible adhésion de leur projet respectif au seul PSR-0 (comprendre, la faisabilité même). Voir leurs interventions ici et ici. Le Working Groupe s'est mis dans la tête de ne travailler qu'avec une seule implémentation d'autoloader. A partir de ce moment là, soit un projet est compatible avec la convention de nommage et la structure de fichiers, soit il ne l'est pas. Au delà d'une convention, c'est toute une architecture logicielle qui est impactée, comme le montrent Garfield et Lemke.

Afin de bien comprendre, et de rigoler un peu, prenons le cas de TYPO3. Chez eux, pour un composant donné, les fichiers de classes sont localisés dans un sous répertoire "Classes" mais ce dernier n'apparait bien évidemment pas explicitement dans le nom complètement qualifié:

class: \TYPO3\Fluid\Core\Parser
file : Packages/Framework/TYPO3/Fluid/Classes/Core/Parser.php

Fluid/
     Classes/
     Core/
         Parser.php
     Meta/
         Package.xml
     Documentation/
         Manual/
               en/
                 Index.xml    

TYPO3 doit donc être entièrement repensé et réécrit. Dommage pour eux. En revanche, Symfony, Doctrine ou ZF s'en sortent bien. Il faut dire que leur représentants sont influents. Par exemple, Jonathan H. Wage (Doctrine - Sensio) est à l'origine de SplClassLoader. Matthew Weier O'Phinney (ZF - Zend) a réussi à imposer la règle spéciale qui consiste à transformer les underscores dans les noms de class en DIRECTORY_SEPARATOR. Cela complexifie fortement l'implémentation de SplClassLoader, mais bon, il s'agit de Zend tout de même!

Ce qu'il faudrait faire

La seule chose importante pour une interopérabilité d'autoloading est l'unicité de la partie <Vendor Name> dans:

\<Vendor Name>\(<Namespace>\)*<Class Name>

Tout le reste n'est que contraintes inutiles. Si une librairie X veut mettre toutes ses classes dans un sous répertoire Classes, elle n'a qu'à fournir sa propre implémentation pour spl_autoload_register(). Dans un contexte de namespaces, l'unicité de <Vendor Name> suffit.

Au passage, les constantes __DIR__ et __NAMESPACE__ permettent potentiellement de se passer d'include_path lors des opérations d'inclusion de fichiers. Quoiqu'il en soit, les auteurs de la librairie X ont tout le loisir d'optimiser au maximum leur implémentation et se passer, par exemple, de la règles des underscores dans les noms de classes.

Mais quid d'une possible implémentation en C de SplClassLoader ? Et bien tant mieux! Rien n'empêche un projet d'adhérer à la lettre au PSR-0. Ce n'est aucunement incompatible avec la présence de plusieurs autoloader. SplClassLoader utilise déja spl_autoload_register.