Et pour ménager le suspense, vu que c'est quasiment la seule information intéressante que j'ai pu extraire de ces dix jours, je vais commencer par parler des modifications effectuées sur le trunk.

Nous retrouvons donc le lot habituel de corrections.

Ainsi, les bugs #53144, #53071, #53180, #49687 et #53198 ont été corrigées.

Les demandes de modification #44164 et #52860 ont également été implémentées.

Cette dernière modification fait d'ailleurs partie du gros travail que Gustavo André dos Santos Lopes, aka cataphract dans la communauté des développeurs PHP, a débuté sur la période précédente et qui concerne entre autre htmlspecialchars() et htmlentities().

Ces deux fonctions ont été réécrites en profondeur et supportent maintenant les constantes ENT_HTML401, ENT_XML1, ENT_XHTML et   ENT_HTML5 qui permettent d'adapter leur comportement au format du document qui doit être généré.

Et c'est encore lui qui a ajouté dans le trunk les fichiers UPGRADING et UPGRADING.INTERNALS, qui décrivent les différences entre la dernière version officielle du langage et la version de développement,  respectivement à destination de l'utilisateur final et du développeur.

Ces fichiers sont la transcription conviviales du fichier NEWS introduit il y a quelques temps, qui a lui pour but de fournir une vision beaucoup plus fine et techniques des modifications effectuées.

Et en les lisant, il est facile de constater que le nom de prochaine version de PHP n'est toujours pas défini, puisque cette dernière y est référencée sous le label PHP X.Y.

Gustavo a également ajouté au langage la méthode ReflectionParameter::canBePassedByValue(), qui, comme son nom l'indique, permet de savoir si un argument d'une fonction ou d'une méthode peut être passé par valeur et/ou par référence.

À ce titre, cette nouvelle méthode est donc le pendant de ReflectionParameter::isPassedByReference().

Dans le même registre, il a également corrigé un bug non référencé dans ReflectionProperty::isDefault(), qui renvoyait un résultat incorrect lorsqu'elle était utilisé en relation avec ReflectionClass::getProperties().

Vous l'aurez compris, Gustavo a été le plus prolifique des développeurs sur la période qui vient de s'écouler, puisqu'il est l'auteur d'un peu moins de la moitié des ajouts et des modifications effectuées sur le trunk.

Andrey Hristov, aka andrey, est quand à lui le second, de par le travail qu'il a effectué sur mysqlnd, en lui ajoutant un mode debug et en le corrigeant et l'optimisant.

Le reste des modifications réalisées sur le trunk sont, comme d'habitude, du nettoyage et de l'optimisation à divers niveaux.

Il est maintenant temps de parler de ce qu'il est passé sur la liste de diffusion des développeurs, internals@.

Comme je l'ai dis en introduction, il y a eu un débat relativement intense et puéril, qui a concerné le renommage de T_PAAMAYIM_NEKUDOTAYIM en T_DOUBLE_COLON.

Pour ceux qui l'ignoreraient encore, T_PAAMAYIM_NEKUDOTAYIM est depuis 12 ans maintenant le nom de la constante interne à l'interpréteur de PHP représentant l'opérateur de résolution de portée ::.

Et le problème est que c'est le nom de cette variable qui est affiché dans le message d'erreur généré par l'interpréteur du langage lorsqu'il rencontre un problème lié à :: :

Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM

Ce message est évidement relativement cryptique, surtout pour celui qui ne connais pas l'hébreu, puisque PAAMAYIM NEKUDOTAYIM signifie deux points en hébreux.

De plus, il existe un alias de cette constante au sein de l'extension tokenizer de PHP, portant le nom T_DOUBLE_COLON.

La demande de renommage est donc relativement compréhensible.

Cependant, le nom de cette constante étant historique et affectif, la proposition a reçu un accueil très froid, d'autant que les contributeurs ont fait preuve de leur mauvaise foi habituelle.

Dieu Rasmus Lerdorf m'a d'ailleurs bien fait rire :

It is a tip of the hat to the amount of PHP work that came out of Israel, and it is a good reminder that there are a lot of other languages in the world.

Je trouve en effet assez risible qu'il dise cela alors que le langage qu'il a créé il ya 20 ans ne supporte toujours pas nativement Unicode.

Pour autant, le débat, indirectement, n'a pas été si stérile qu'il aurait pu semblé l'être au premier abord.

En effet, le sujet relatif à la réécriture de l'interpréteur de PHP en utilisant lemon s'est invité dans la conversation, et cela a été l'occasion d'apprendre que les problèmes de performances lié à l'utilisation de lemon n'étaient toujours pas réglés et qu'en conséquence, il y avait pour l'instant peu de chance de voir bison abandonné un jour.

Enfin, il n'y a toujours eu aucune information de diffuser au sujet d'une éventuelle version alpha de la prochaine version majeure, malgré la question posée à ce sujet il y  a une vingtaine de jours.

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