Sur les 16 modifications faites sur le trunk, 7 sont des corrections de bugs.

Le bug #54358 que j'avais détecté lors de la sortie de PHP 5.3.6 grâce aux tests unitaires d'Atoum a par exemple été corrigé, ainsi que les bugs #54039, #54494, #54440, #54121, #54238 et #54268.

Deux autres modifications correspondent à l'implémentation de fonctionnalités demandées par les utilisateurs du langage.

La version de PHP contenue dans le trunk est donc maintenant capable de se connecter à une base de données à l'aide du protocole SSL via PDO, tandis que la gestion des ressources d'intl a été améliorée.

Par ailleurs, le patch proposé par Sebastian Bergmann lors de la période précédente visant à ajouter un argument à la fonction debug_backtrace() afin de ne récupérer qu'un nombre limité de traces a été appliqué sur le trunk.

La documentation de la fonction a été mise à jour en conséquence, et on peut y remarquer que la prochaine version y est désignée sous le nom de PHP 5.4.

De là à dire qu'il s'agira bien du nom de la version correspondant au trunk, il y a un pas que j'hésite à franchir, mais je pense que c'est tout de même un indice recevable, d'autant que j'ai eu des informations complémentaires via internals@.

Cela sous-entend cependant qu'il ne s'agira pas d'une majeure en tant que telle, mais si elle est de la même veine que PHP 5.3, je pense que nous ne nous en plaindrons pas.

La dernière modification significative est l'ajout de la constante PHP_MANDIR, qui contient le chemin d'accès au répertoire des pages du manuel de PHP, les autres étant des optimisations diverses et des corrections visant à améliorer la fiabilité du langage et la lisibilité de son code.

Comme je l'ai dis en introduction, l'activité a été beaucoup plus intense sur internals@.

Le débat débuté sur la période précédente au sujet de l'opérateur ternaire et de la possibilité de lui permettre de ne pas générer d'erreur lors d'un test sur une variable indéfinie s'est poursuivi et a quasiment monopolisé l'attention des contributeurs.

Plusieurs propositions différentes ont en effet été faites pour obtenir ce comportement, comme par exemple l'introduction d'un opérateur dérivé de l'opérateur ternaire et qui serait représenté par ?? et qui aurait le comportement suivant :

<?php
...
// Fonctionnement standard de l'opérateur ternaire
$value = isset($a[$key]) ? $a[$key] : 'Indéfini';
// Utilisation de ?? pour éviter l'appel à isset()
$value = $a[$key] ?? : 'Indéfini';
// Utilisation de ?? d'une manière similaire à l'opérateur ternaire
$value = $a[$key] ?? strtoupper($a[$key]) : 'Indéfini';
...
?>

Le débat a de plus dérivé sur le sujet de l'opérateur @ et de l'ajout du mot-clef silent pour le remplacer dans les cas ou la propagation et surtout la gestion de l'erreur ne doit pas être possible, ce que ne permet pas @.

Comme d'habitude dans ce genre de situation, le débat s'est étouffé de lui-même, sans qu'aucune décision soit prise.

Pour autant, cela ne veut pas dire que les idées énoncées lors de la discussion vont partir aux oubliettes, et il donc très possible de voir l'une ou l'autre de ces solutions intégrées dans le langage à plus ou moins longue échéance.

Il a également été proposé d'intégrer le patch permettant de disposer d'un serveur HTTP au sein même du langage.

Pour le moment, la proposition, qui avait déjà rencontré un accueil chaleureux par le passé, a été plutôt bien accueilli, même si Andi Gutmans semble vouloir, avec raison, mettre vraiment l'accent sur le fait qu'il s'agit uniquement d'un outil de développement.

Enfin, une discussion a commencé au sujet d'une hypothétique version 5.4, qui serait une version mineure basée sur le trunk.

Pour l'instant, rien n'est réellement décidé, d'autant que Pierre Joye, l'un des instigateurs de la RFC relative à la gestion du processus de release du langage, n'a pas encore pris part au débat, et qu'il était ressorti de ma dernière discussion avec lui sur le sujet que ce n'était pas encore le bon moment pour faire cela.

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

Cette information est donc, malheureusement, à prendre avec des pincettes et il faut donc attendre pour savoir ce qu'il en sortira exactement.