Tout d'abord, il a été demandé s'il était pertinent de porter des extensions PECL, donc écrite en C, vers PHP afin que leurs fonctionnalités soient disponibles même si l'extension correspondante ne peut pas être installée, et s'il y avait un moyen d'automatiser, au moins partiellement ce portage.

Il a été répondu que cela était possible pour certaines extensions, mais qu'il n'y avait pas de méthode générique pour le faire et qu'il y aurait évidemment une perte de performance significative et que cela était un énorme travail. La discussion est ensuite partie gentiment en vrille, les participants ayant décidé de disserter sur la pertinence d'écrire ou non des extensions en C pour PHP.

Il a été ensuite proposé de remplacer l'implémentation actuelle de mbstring au sein du langage, qui présente un certain nombre d'inconvénients décrits dans la RFC correspondante.

Cette proposition revient de loin, puisque le sujet avait été évoqué pour la première fois en 2009, mais pour autant, pour l'instant, rien n'a été décidé et il n'est donc pas dit que cette nouvelle implémentation soit disponible rapidement, que ce soit au sein de PHP ou sous la forme d'une extension.

La discussion au sujet de l'utilisation d'un DCVS pour gérer le code source de PHP est également revenu sur le devant de la scène, mais tout comme dans le cas de l'implémentation alternative de mbstring, rien n'a avancé, même si une RFC devrait être rédigée rapidement.

Une autre RFC a été exhumé du wiki, puisque Ilia Alshanetsky a proposé d'intégrer un patch datant de juillet 2008 améliorant la gestion des signaux au niveau du Zend Engine à PHP 5.4.

Sa suggestion a été accueillie favorablement, et le patch est actuellement en train d'être mis à jour et corrigé en vu de son intégration à la prochaine version du langage.

La RFC concernant les énumérations a elle aussi refait surface et devrait évoluer prochainement, mais comme d'habitude, il y a eu plus de questions soulevée que de réponses trouvées à son sujet.

Enfin, une RFC concernant l'intégration d'une classe de gestion de sessions a été soumise à l'avis des contributeurs, mais elle n'a pas pour l'instant suscité énormément d'intérêt parmi eux.

Plus exotique, il a été demandé de pouvoir désactiver le logo de PHP à la compilation, mais j'avoue ne pas en avoir compris la raison, ni avoir eu envie de la chercher.

Il y a également eu un débat au sujet de l'infini, et plus précisément sur ce que devait donner comme résultat les expressions INF == INF et INF === INF, et pour l'instant, le résultat est indécidable.

En effet, certains veulent un comportement identique à celui de NULL, à savoir que INF == INF et INF === INF soient égaux à TRUE, tandis que d'autres désirent un comportement similaire à celui du SQL et que INF == INF retourne FALSE tandis que INF === INF retourne TRUE.

L'un des deux plus gros débat de ces 10 12 derniers jours a été sans conteste celui portant sur la RFC relative au futur processus de release de PHP et le vote qui en a découlé.

Il semble en effet que le consensus soit encore loin, au vu des réactions que la proposition, pourtant rédigé par les principaux développeurs actifs du langage, a suscité.

Les principaux points d'achoppement concerne assez paradoxalement le système de vote, à la fois celui mis en place pour entériner la RFC que celui décrit par la RFC, et la question du support des versions du langage sur le long terme.

Il y a donc clairement encore un gros travail d'évangélisation à réaliser avant que cette proposition soit adoptée, d'autant que le vote est actuellement suspendu, apparemment au moins jusqu'à ce qu'un outil qui convienne à la majorité des contributeurs soit mis en place pour le réaliser.

Cependant, le plus gros débat a été sans contestation possible celui concernant la possibilité de définir des tableaux via une notation plus courte, c'est à dire sans passer par le mot-clef array et à l'aide de [ et ].

Il a généré à lui seul pas loin de 150 messages, sans compter ceux qui ont été échangé dans le cadre des discussions annexes qu'il a provoqué.

Les choses avaient pourtant bien commencé, puisqu'un vote avait été lancé très rapidement pour la valider définitivement, mais les choses se sont gâtées très rapidement.

En (très) résumé, l'intérêt de la proposition a été remis en cause une nouvelle fois, ainsi que la syntaxe proposée, et des modifications substantielles et parfois formalisées, comme cette RFC suggérant l'utilisation de la notation JSON ou l'utilisation de : au lieu de => pour la définition des paires clef/valeur dans un tableau.

De plus, la procédure de vote elle-même a été remise en cause, vu que le débat a été pollué par celui relatif au processus de release du langage.

Les contributeurs sont donc très loin d'être d'accord entre eux au sujet de cette fonctionnalité, et d'après mes dernières informations, suite aux remarques de Zeev Suraski, tout comme dans le cas du processus de release, il semblerait qu'un nouveau vote sera effectué lorsque les choses auront été mises à plat à ce niveau. 

Certain ont également tenté de faire avancer les choses sur le front de la prochaine version significative du langage, la mal bien nommée 5.4.

Malheureusement, cette discussion, qui promettait pourtant d'être intéressante, a également été polluée par les problèmes posés par la procédure de vote et le processus de release, et n'a donc pas débouchées sur des choses significatives.

Andi Gutmans a de son côté proposé d'intégrer des extensions permettant d'apporter à PHP nativement des technologies modernes, comme par exemple MongoDB, un serveur de base de données utilisant les principes du NoSQL.

Les contributeurs ne parviennent cependant pas à se mettre d'accord sur l'intérêt de faire cela, ni sur les critères qui permettrait de décider les extensions PECL qui seraient ainsi ajoutée au cœur du langage.

Et ce n'est pas la proposition d'intégrer une syntaxe rappelant la programmation fonctionnelle sous l'appellation de currying qui a calmé les débats, bien au contraire, et encore moins celle visant à pouvoir invoquer un callback, le clivage entre les contributeurs progressistes et les ceux très traditionnalistes étant toujours présent.

Grâce au currying, il deviendrait possible d'écrire par exemple :

<?php
// curry et ... sont des mots-clef !
func = curry str_replace(..., ..., "foobar");
$func('foo', 'bar'); // barbar
$func('foo', 'baz'); // bazbar
?>

La possiblité d'invoquer un callback permettrait quand à elle de faire :

<?php
class Hello { function print($who) { echo 'Hello ' . $who . PHP_EOL; } }
$callback = array('Hello', 'print');
$callback('world');
?>

Patrick Allaert a également proposé un patch qui a fait débat parmi les contributeurs et qui a pour but la génération d'une erreur de type E_NOTICE lors de la conversion d'un tableau en chaîne de caractères ayant la valeur Array.

Le patch a été bien accueilli, mais certain aurait voulu aller encore plus loin et générer une erreur d'un niveau plus élevé, mais la volonté de conserver une compatibilité avec le code existant rend cela impossible, et en conséquence, le code correspondant devrait donc être prochainement intégré dans le trunk.

Pour continuer dans la lignée du déréférencement des tableaux et des constructeurs, il a également été proposé de généraliser encore plus le principe des interfaces fluides en permettant d'appeler une instance de classe dès qu'elle a été clonée, et de rendre l'instruction foreach plus souple, de la manière suivante :

<?php
$tomorrow = (clone $today)->add($one_day);
foreach ($arrays as list($e1, $e2, $e3)) {}
// Pour remplacer :
foreach ($arrays as $array) { list($e1, $e2, $e3) = $array; }
?>

Ces deux propositions, dont l'une reprend un principe déjà soumis à la communauté par le passé, n'ont pour l'instant pas suscité de grosses réactions de la part des développeurs.

Enfin, une question par rapport à la pertinence de développer et d'utiliser Quercus, un équivalent au Zend Engine et basé sur la JVM, a été posée, et les contributeurs ont répondu qu'ils ne voyaient pas énormément d'intérêt à investir du temps dans un projet de ce type.

La liste de diffusion des contributeurs est donc en pleine ébullition, et moi qui me plaignait de son calme il y a quelques temps, j'en viendrais presque à regretter cette époque tant j'ai du mal à suivre le rythme actuel, d'autant que l'activité sur le trunk n'est pas en reste.

Ce dernier a en effet subit pas loin de 70 modifications, dont presque un tiers sont des corrections, puisque les bugs #54934, #54137, #53848, #54601, #54946, #52496, #54957, #54910, #54484, #52104, #54970, #54896, #54918, #54929, #54609, #51819, #51997, #47160, #55007, #54992 et #53540 ont été supprimés.

La plupart des autres modifications ne sont cependant que des optimisations, du nettoyage ou bien de l'ajout ou des mises à jours de tests unitaires, même si certaines d'entres elles visent à corriger des problèmes potentiellement sérieux tel que des crashs du Zend Engine.

Pour finir, la version minimale d'autoconf supportée par PHP est dorénavant la 2.59, car la version 2.60 n'est pas disponible nativement dans certaines distributions de Linux, telle que Centos, RHEL ou Oracle Linux 5.6.

Cette rétrospective est maintenant terminée, vous pouvez reprendre une activité normale.