Conférences sur l’interopérabilité des frameworks PHP

Le 2 avril a été organisé chez Microsoft Venture Accelerator – l’incubateur d’entreprises par Microsoft – une soirée autour de 3 conférences dédiées à l’interopérabilité des frameworks PHP.

1ère : Frédéric Marand & le

Frédéric Marand est le directeur d’Osinet, une agence très active autour de Drupal. Il est revenu sur les origines du FIG – Framework Interoperability Group, sur son mode de fonctionnement et a évoqué les PSR déjà adoptées et celles en cours.

L’organisation du FIG

Le FIG a été créé en 2009 pour standardiser l’utilisation des namespaces, convention de nommages pour les classes, interfaces et classes de bases abstraites & l’utilisation des exceptions (on notera l’absence des traits qui n’étaient pas encore implémentés à cette époque). 38 projets participants aujourd’hui, notamment des frameworks purs mais également par extension des CMS.

L’organisation du FIG se fait autour des projets adhérents. Cette notion est importante car au FIG, 1 projet dispose d’une voix. Cela signifie que les 32K développeurs Drupal comptent autant que les 30 développeurs de Contao. Quelques exceptions à cette règle sont néanmoins en vigueur : 2 projets représentés par 1 seule personnes et comptent pour 1 voix (ie. les projets Aura/Solar, Composer/Packagist).

Le FIG est organisé autour d’un principe de discussion ouverte mais vote fermé. Chacun peut participer, proposer une PSR et commenter les PSR proposées tant que le vote n’est pas en cours. Frédéric a insisté sur le fait que les propositions étaient réellement écoutées et a pris pour exemple la PSR-3 – qui traîte des interfaces de logging – qui a été soumise par Monolog, étendue par 3 membres de Drupal (qui comptaient donc pour 1 seule voix).

Il est intéressant également de savoir que le FIG adopte le formalisme apporté par la RFC 2119 qui donne des sens particuliers aux termes MUST / SHOULD / MAY, etc. Egalement les membres du FIG ne sont pas liés par les PSR. Quand bien même ils auraient voté pour une résolution, ils ne sont pas contraints de l’appliquer dans leurs projets.

Pour adopter une PSR – PHP Standard Recommendation – la discussion est réalisée sur le groupe google du FIG. Cette discussion est entièrement publique et ouverte. Le vote est ensuite réalisé de manière fermée mais non anonyme sur une période de plusieurs semaines. Il est à noter que le membre qui a proposé la PSR peut la retirer même lors du vote. Par exemple la PSR-4 a été retirée durant le vote alors qu’elle allait passer à une large majorité – le membre qui l’avait soumise s’étant rendu compte qu’il y avait eu des mauvaises compréhensions. S’en est suivie une réécriture de la PSR avant qu’elle soit adoptée 2 ans plus tard.

Les PSR déjà adoptées et celles en cours

PSR-0 : l’autoloader

La PSR-0 traite de l’autoloader et pose certaines contraintes. Notamment l’utilisation des namespaces qui permettent de détailler le chemin du fichier sur le filesystem. 1 classe par fichier et pas de code en dehors de la classe. La PSR-0 traite également une couche de compatibilité avec PEAR qui utilisait des « Pseudos-namespaces » (i.e : Classe_MaClasse pourrait se traduire en un namespace ClasseMaClasse).

Frédéric Marand a souligné le fait que c’est l’alliance composer + packagist qui a réellement modernisé et relancé PHP. En étant compatible PSR-0, composer a montré aux développeurs l’intérêt de la PSR-0.

PSR-1 : Conventions « utiles »

  • Requiert PSR-0
  • Formats de fichiers : UTF-8 sans BOM (sans surprise)
  • Tags <?php ou <?=. Pas de tag style ASP ou tag court
  • Une classe doit traiter des symboles (templating) OU des effets de bords (ie : connexion à une base de données)
  • Un peu de style mais pas de recommandation stricte

PSR-2 : Conventions « futiles »

  • Requiert PSR-1
  • Visibilité spécifiée obligatoire
  • switch case sans break entre 2 cas autorisé mais une ligne de commentaire doit être insérée pour le justifier
  • Pseudo-protégé par « _ » déconseillé
  • abstract|final <visibility> static
  • 1 instruction / ligne, minuscules, 1 use par import de namespace
  • Formatage de l’espace blanc
  • Pas spécifié:
    • Déclarations, alignements, commentaires
    • Nommages, bonnes pratiques

PSR-3 : le logging

  • Emergé par le design de Monolog
  • Inspiré par la RFC 5424 (syslog)
    • LogLevel : les 8 niveaux définis
      • Constantes de Log redéfinies ici car pas présentes si PHP compilé sans syslog
    • LoggerInterface : 1 méthode / niveau + log
  • log($level, $message, $context)
    • Exception sur niveau invalide
    • Message surpoort au moins de string et object ::__troString
    • context :
      • valeurs des placeholders
      • l’implémentation doit tout accepter sauf des exceptions
      • sauf dans la clé exception qui peut aussi contenir autre chose
      • en cas de problème lors du log:
        • pas de throw
        • pas d’erreur
  • AbstractLogger : les 8 méthodes, invoque log()
  • LoggerTrait
  • NullLogger : (Fausse Bonne Idée : coût du contexte)
  • LoggerAwareInterface
  • LoggerAwareTrait

PSR-4  : Le package autoloader

(Moins détaillées à partir d’ici, voir le site du fig pour toutes les infos)

  • Support des filesystems non Unix
  • Pas de code proposé (car trop souvent repris comme un code parfait)

Les PSR en cours de discussion:

  • PSR-5 : PHPDoc
  • PSR-6 : le cache
  • PSR-7 : l’implémentation HTTP

Pourquoi le FIG est parfois détesté à tord

Le FIG engendre parfois des réactions épidermiques liées à son histoire. Le FIG est né en 2009 lors d’une rencontre informelle entre plusieurs concepteurs de frameworks qui souhaitaient mettre en place une couche d’interopérabilité entre leurs composants.

Au lendemain de cette réunion informelle une liste fermée a été créée sur php.net et nommée « standards ». Celle-ci a engendré des réactions virulentes puisque les membres actifs de la communauté à l’époque ne souhaitaient pas qu’on vienne leur imposé des standards.

Sous la pression de Rasmus Lerdorf, la liste a été ouverte et déplacée vers le groupe google qui existe aujourd’hui. Cependant il faut préciser que le FIG n’a pas vocation à standardiser tous les projets qui existent. Le FIG n’a que pour vocation a mettre des standards entre ses membres. Il peut-être intéressant cependant lorsqu’on est développeur d’un framework de suivre ses recommandations pour bénéficier plus facilement des composants apportés par les autres frameworks.

2nde conférence: Interopérabilité des containers d’injection de dépendance

Cette conférence a été donnée par David Négrier, CTO de The Coding Machine et traite d’une future PSR qu’il souhaiterait soumettre.

David Négrier a commencé à écrire en 2009 un framework d’injection de dépendance avec configuration par une interface web, sans se rendre compte que l’injection de dépendance serait l’apport principal des frameworks de 2nde génération. C’est ainsi qu’est né Mouf.

Petit à petit, les briques de l’époque n’apportant que peu d’interopérabilité, il a construit un framework full-stack autour de son idée d’injection de dépendance par interface graphique. Depuis, il souhaiterait pouvoir simplement reprendre sa brique d’injection de dépendance et l’interchanger dans un framework existant.

Il s’est donc posé la question de savoir ce qui faisait la spécificité réellement d’un container d’injection de dépendance et ce qui pouvait relever de la standardisation. Selon lui le découpage est le suivant:

  • Configuration
  • Container
  • Récupération

Selon lui c’est vraiment la partie récupération qui est standardisable et qui en a le plus besoin. C’est comme ça qu’il sont arrivés au projet de ContainerInterface visible sur le github du projet: https://github.com/container-interop/container-interop. Il travaille également sur un 2nd point qui permettrait d’exploiter différents containers dans un même projet, grâce à une interface composite.

Vous aimerez aussi...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *