Sur la liste de diffusion des contributeurs, internals@, il n'y a rien de bien croustillant à ce mettre sous la dent.

La proposition d'inclure un langage de macro-définitions similaire à celui du C faite lors de la période précédente a été définitivement enterrée, fermement et sans violence.

Il faut dire que le sujet revient régulièrement et que les développeurs, par la force des choses, sont parfaitement rompus à cet exercice, et sont de plus, pour une fois, approximativement sur la même longueur d'onde sur ce point précis.

Dans un registre similaire, Nicolas Grekas, l'auteur du framework patchwork, présenté lors du forum PHP 2009, a fait une proposition visant à supprimer le support des espaces de nommage pour les fonctions et les constantes.

En contrepartie, il a proposé de donner la possibilité d'inclure tout ce que contient un espace de nommage uniquement à la demande, via une modification du mécanisme d'autoload.

Le moins que l'on puisse dire est que ses suggestions ont été très loin de remporter tous les suffrages, mais il faut dire que la forme n'était pas à mon sens la mieux choisie, puisque Nicolas a tenté de démontrer que sa proposition était intéressante en disant que d'après lui, personne ne définis de fonctions et de constantes dans un espaces de nommage.

Or, ce n'est pas parce que Doctrine 2 ne le fait pas qu'il n'y a pas quelqu'un dans le monde qui le fait, ce qui est d'ailleurs le cas puisque Atoum dispose de constantes rattachées à son espace de nommage, par exemple.

Je précise que je me permet cette remarque car je pense avoir indirectement poussé Nicolas à faire cette proposition, suite à une discussion que j'ai eu récemment avec Amaury Bouchard, et que même si ce n'est pas le cas, j'espère que Nicolas ne se découragera pas et réitérera l'expérience dans un proche avenir.

Dans un autre registre, un patch a été proposé pour améliorer les performances du langage, grâce à une série d'optimisation au niveau du Zend Engine et au prix d'une légère augmentation de l'empreinte mémoire, et après une relecture attentive, il devrait être intégré dans la version de développement.

Enfin, pour en terminer avec internals@, Rune Kaagaard a proposé de rédiger la grammaire de PHP à l'aide de la notation EBNF, sur le modèle de ce qui existe pour Python.

Son initiative a été perçue comme une très bonne chose pour le langage, car il n'existe à ce jour aucun outil de ce type, principalement parce qu'il n'existe aucune documentation sur ce sujet et que la syntaxe du langage contient un grand nombre de cas particuliers et plusieurs façon, syntaxiquement parlant, d'écrire un même code.

L'actualité du trunk, qui contient la version de développement de PHP, n'a pas été plus trépidante que celle de la liste de diffusion des contributeurs.

Le lot habituel de correction et d'optimisation est toujours présent, ainsi que le lot de correction de bugs, puisque ceux numérotés #53606, #53603, #53612 et #53629 ont été éradiqués.

La version de développement de PHP, suite à la demande #48767, dispose également maintenant de la méthode \splFileInfo::getExtension(), qui permet d'obtenir l'extension d'un fichier à la manière de pathinfo() lorsqu'elle est appelée avec la constante PATHINFO_EXTENSION en deuxième argument.

L'extension mysqlnd, le pilote natif pour mysql, a également été modifiée afin de pouvoir mieux supporter les greffons à l'avenir, tandis qu'il n'est plus possible de transformer une chaîne de caractères en objet en définissant dynamiquement une propriété, puisque lorsqu'il est configuré en mode strict, PHP générera dorénavant une erreur.

Le code suivant produira donc une erreur de type E_STRICT avec les prochaines versions du langage :

<?php

$x = ''; // ou null, ou false.
$x->baz = 1;

?>

Enfin, pour terminer sur une note d'humour, un grand nombre de fichiers, pour ne pas dire la totalité, ont été impactée par cette modification, et peut être faut-il y voir la carte de vœux des développeurs du langage pour 2011.

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