Comme à l'habitude, afin de ménager le suspense, je vais commencer par décrire les modifications effectuées sur le trunk.

Il y en a eu soixante-dix, et la majorité d'entre elles sont des corrections de bugs ou de tests unitaires, mais en cherchant bien, il y a une information intéressante.

Ainsi, les bugs #51250, #53440, #29085, #53463, #53492, #53511, #39199, #53512, #53512, #53517, #53515, #26158, #53503, #53425, #53150, #47435, #53530, #53493, #53493 et #48607 ont été corrigés.

Par ailleurs, les demandes utilisateurs #53447, #53457 et #53457 ont été implémentées.

Il sera donc possible avec la prochaine version de PHP d'ouvrir via fopen() le descripteur de fichier de son choix, comme par exemple ceux disponibles dans /dev/fd et cela aussi bien sous BSD que Linux et le support de openssl a été amélioré dans certain contexte d'exécution spécifique.

Les développeurs auront également enfin la possibilité de définir un séparateur de plus d'un caractère pour le séparateur des centaines lors de l'utilisation de la fonction number_format().

Des modifications ont également été effectuée afin de faciliter la compilation du langage sous Windows, améliorer les tests unitaires et enfin permettre la compilation de PHP via le même processus que sous UNIX via phpize.

La gestion des traits, toujours en cours de finalisation, a également été légèrement modifiée.

En effet, suite à une discussion sur internals@, une collision au niveau d'un nom de méthode lors de l'injection d'un trait dans une classe à la compilation du code PHP générera une erreur du type E_COMPILE_ERROR.

Toujours suite à une discussion sur la liste de diffusion, le paramètre de configuration enable_post_data_reading a été ajouté, afin de pouvoir empêcher PHP d'effectuer le traitement correspondant à la RFC 1867 sur les données contenues dans $_POST et ainsi conserver les données brutes.

Le fait de ne pas traiter systématiquement peut en effet être intéressant dans le cas de développement particulier, par exemple dans le cadre de services web.

Cependant, comme je l'ai annoncé en introduction, il y a également eu d'autres discussions sur internals@.

Un vif débat a éclaté suite à la proposition de supprimer le mot-clef global et la variable $GLOBALS correspondante.

L'objectif de cette proposition est de rendre PHP moins permissif et d'ainsi éviter le phénoméne du code spaghetti.

Évidement, pour des raisons qui me semble évidentes et que je ne détaillerai pas, cette suggestion n'a pas du tout reçu un accueil favorable.

Dans un autre registre, le débat concernant la RFC relative à la définition automatique d'accesseurs à la façon de C#, qui a commencé lors de la période précédente, a continué à déchaîné les passions, mais pour l'instant, elle n'est toujours pas acceptée.

Une nouvelle RFC a également été proposée, qui a pour but de généraliser le fonctionnement de l'autoloading aux fonctions, voir même aux variables.

Elle a pour le moment reçu un accueil favorable, et il est donc possible que cette fonctionnalité soit un jour incluse dans le langage.

Une autre RFC a également été proposée, visant à permettre la définition de l'espace de nommage d'un fichier lors de son inclusion, ainsi que de permettre au développeur de choisir entre les balises  <? et <?php lors de l'inclusion.

Elle n'est cependant pas encore formalisée dans le wiki correspondant, et n'a reçu encore aucun commentaire.

Par ailleurs, la proposition de rendre le mot-clef function optionnel semble définitivement enterrée.

De plus, les discussions concernant la gestion du projet PHP en lui-même se sont calmées, ainsi que celles relatives au choix d'un nouveau système de gestion de version.

Sur ce point précis, une RFC récapitulant les débats et proposant une ou plusieurs solutions devrait être prochainement rédigée.

Dans un autre registre, il a été proposé d'empêcher la modification d'un objet \dateTime une fois qu'il a été instancié, mais pour des raisons techniques, cela ne semble pas possible pour le moment, voir même incohérent par rapport au fonctionnement de la classe, du moins au regard de l'implémentation proposée.

Enfin, des discussions sont en cours afin d'éclaircir le fonctionnement des traits, qui ne semble pas encore bien clair à certain.

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