Il n'a cependant pas reçu la moindre réponse à sa demande au moment où j'écris ces lignes.

Et en attendant une réponse éventuelle au sujet d'un futur hypothétique, je me propose de vous parler du présent, même si je suis bien obligé d'avouer qu'il n'a rien de bien passionnant.

Le lot de correction de bugs est présent, comme d'habitude, mais contrairement aux périodes précédentes, il est beaucoup plus petit.

Ainsi, les bugs #49407, #25927, #52939, #53070 et, #53089 ont été corrigés, tandis que le bug #53006 est en cours de résolution.

Par ailleurs, la fonction get_html_translation_table() accepte maintenant un troisième paramètre permettant d'indiquer l'encodage devant être utilisé, comme dans le cas de htmlentities().

Cela semble confirmer que la gestion des jeux de caractères en général et d'Unicode en particulier au sein de PHP revient peu à peu au premier plan des préoccupations de certains développeurs, même si c'est par la très petite porte et qu'il s'agit de solutions très partielles qui n'ont rien à voir avec une gestion beaucoup plus globale.

Dans un registre différent, PHP est maintenant capable de détecter les éditions Starter, Tablet PC et Media Center de Windows, même si pour l'instant la version Server 2008 n'est toujours pas reconnue correctement.

Le reste des modifications concerne diverses optimisations au sein du Zend Engine, ainsi qu'une correction dans la classe zipArchive::getArchiveComment() et au niveau de la gestion des flux.

Au passage, sqlite a été mis à jour et PHP embarque dorénavant la version 3.7.3.

La liste de diffusion des contributeurs a été également relativement calme, même si un membre de la liste a relevé un dysfonctionnement, pour parler diplomatiquement, dans le processus de gestion des rapports de bugs.

Évidemment, aucun commentaire n'a été fait sur le dysfonctionnement signalé, et la suite de la discussion a été exclusivement réserver à l'aspect fonctionnel du problème soulevé par le rapport de bug mentionné.

Il y a également eu une tentative de relance du débat relatif à la gestion de paramètres nommés par le langage.

Il s'agit d'un vieux serpent de mer qui revient régulièrement à la surface, même si les discussions à ce sujet sont considérées comme closes et qu'il a été décidé depuis 2005 que PHP n'implémentera jamais ce type de fonctionnalité, car cela compliquerait inutilement le langage.

Ce détail a d'ailleurs été signifié avec délicatesse et gentillesse à celui qui a relancé le débat, même si certain ont essayé de tempérer les choses en précisant que des fonctionnalités refusées maintes fois par le passé ont finalement été intégrées, comme par exemple les espaces de nommage et que les choses pouvaient, voir devaient, évoluer.

La rudesse de la réponse n'a cependant pas empêché qu'il soit relancé une nouvelle fois dans le cadre d'une discussion visant à permettre de ne pas définir de valeur pour des arguments optionnels si cela n'est pas nécessaire, par exemple de cette façon :

<?php

function foo($var1, $var2 = 2, $var3 = 3)
{
echo "$var1, $var2, $var3\n";
}
foo(10,, 30);

?>

Cependant, cela n'est pas plus passé que la première fois, et encore une fois, toute discussion sur le sujet a été refusée.

Enfin, Derick Rethans a recommencé à travailler sur le contrôle du type des arguments, et les choses semblent aller relativement vite et être conforme aux décisions prisent lors du dernier débat à ce sujet.

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