Ce mois-ci sur internals@php - Octobre 2013

Après septembre et ses 625 mails, voici mon dépilage d’internals@ pour le mois d’octobre 2013, qui est arrivé à un total de 562 messages.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

Depuis quelques mois, de nombreuses RFC ont été rédigées, visant PHP 5.6.

David Soria Parra, RM de PHP 5.4 et co-RM de PHP 5.5, a annoncé que, pour s’en tenir au planning prévu, PHP 5.6 devrait sortir en version stable dans 10 mois (c’est une coïncidence, mais cela permettrait à PHP 5.6 d’être inclue dans la prochaine Debian Stable, prévue pour dans 14 mois) – et que les dernières versions sorties avaient montré qu’il fallait environ 5 mois pour stabiliser une version et passer les phases alpha/bêta/RC.

Son mail indiquait qu’il était donc temps de commencer à réfléchir à l’organisation de la sortie de PHP 5.6, ainsi que de penser à trouver un RM pour cette version, afin qu’il ait déjà le temps d’apprendre sur PHP 5.5 – par la suite, plus de précisions sur le rôle du RM ont été données. Après quelques discussions, il est ressorti que les deux RM de PHP 5.6 seront Julien Pauli et Ferenc Kovacs.

En toute fin de mois dernier, Joe Watkins a annoncé avoir commencé à travailler sur la RFC: Nested Classes, qui pourrait par exemple être pratique pour les développeurs de bibliothèques ne souhaitant pas exposer certaines classes censées être utilisées uniquement en interne.

L’idée étant un peu complexe et demandant probablement plus de réflexion, Joe Watkins a fini par se demander si elle n’attendrait pas PHP 5.7, afin de ne pas arriver à une fonctionnalité pas assez réfléchie pour PHP 5.6.

En parallèle, il a annoncé l’ouverture des votes pour la RFC: Anonymous Classes – qui a finalement a été rejetée, avec 23 votes contre pour 9 votes pour.

Michael Wallner a noté que les variables super-globales $_GET et $_POST pouvaient être source de confusion, puisqu’elles peuvent être renseignées plus ou moins indépendamment de la méthode HTTP utilisée (Johannes Schlüter a par la suite fait remarquer que ces noms de variables correspondaient à ce qui est utilisé pour les formulaires HTML). Il a donc proposé de renommer $_GET en $_QUERY, et $_POST en $_FORM ; et, au passage, d’exposer les analyseurs de corps de requête à l’espace utilisateur, et de les déclencher indépendamment de la méthode HTTP utilisée.

Comme l’a rapidement fait remarquer Alexey Zakhlestin, ce renommage de variables casserait la quantité énorme de code les utilisant – mais les deux autres idées seraient intéressantes. Il n’était d’ailleurs pas le seul de cet avis.

Notons tout de même qu’exposer des parsers supplémentaires, si ce choix est retenu, doit être fait avec prudence : comme l’a rappelé Nikita Popov, cette idée a déjà mené à des vulnérabilités dans d’autres langages.

Joe Watkins a lancé un sujet de conversation, où il essayait d’attirer l’attention sur le fait que les assertions de PHP sont assez pauvres – d’ailleurs, est-ce que cela ne serait pas une raison pour laquelle elles sont si peu utilisées ?

Après quelques discussions tournant notamment autour de la levée d’erreur ou d’exceptions, Joe Watkins a annoncé avoir rédigé la RFC: Expectations¹. Avec 50 mails dans la conversation, sans compter les échanges sur la discussion précédente, c’est visiblement le sujet qui a le plus attiré l’attention ce mois-ci.

Les premiers retours ont semblé être plutôt positifs, même si l’introduction d’un nouveau mot-clef expect pourrait causer des problèmes de compatibilité.

Suite à un mail où Derick Rethans faisait remarquer que la RFC n’apportait aucune indication quant à l’utilité de cette proposition par rapport à assert(), il a été répondu que la fonctionnalité aujourd’hui apportée par assert() était peu performante, et qu’elle ne pouvait pas être désactivée facilement en environnement de production, assert() étant une fonction et non une construction langage associée à un opcode. Joe Watkins a aussi apporté en réponse des précisions sur l’aspect erreur vs exception.

Les échanges s’étant fait plus rares en fin de mois, il y a des chances que cette RFC soit ouverte au vote sur les prochaines semaines.

Rowan Collins a proposé de marquer la fonction create_function() comme obsolète, considérant que le gros des usages (mais pas tous) pouvaient, depuis PHP 5.3, être remplacés par des utilisations de fonctions anonymes.

En effet, comme l’a souligné Nikita Popov, passer par create_function() est lent, consomme de la mémoire, et introduit parfois un risque en termes de sécurité.

Cela dit, Pierre Joye a répondu que de nombreuses fonctionnalités des versions récentes de PHP permettent d’écrire du code plus propre que celui que nous écrivions par le passé, mais que ce n’était pas une raison suffisante pour lever des notices partout – d’autant plus que create_function() est assez fortement utilisée, et fonctionne. Dans le même temps, supprimer cette fonction (ce qui est une suite logique, une fois qu’elle a été marquée comme obsolète ; mais ce serait pour PHP 5.7 ou plus, donc dans plusieurs années !) serait problématique pour des projets acceptant encore PHP 5.2 – Ryan McCue a ainsi noté que pour Wordpress, en cas de suppression de PHP, cette fonction devrait être ré-implémentée côté utilisateur (ce qui ne l’a pas empéché, sauf erreur d’interprétation de ma part, de trouver la proposition intéressante).

Nikita Popov a annoncé avoir rédigé la RFC: Exceptions in the engine, dont le but est de permettre la levée d’exceptions depuis le moteur de PHP, et de remplacer certaines Fatal Error par des levées d’exceptions.

Il a ensuite répondu à ceux qui s’inquiétaient des possibles impacts au niveau de la compatibilité entre versions de PHP, en soulignant que, quoi qu’il en soit, une Fatal Error ne correspondait déjà pas à un fonctionnement normal ni souhaité d’un programme. Autrement dit, le seul changement qui serait visible correspond à un cas où un script ne fonctionnait déjà pas.

Plusieurs ont indiqué trouver l’idée extrêmement intéressante, voulant même parfois aller plus loin que le remplacement de seulement quelques erreurs fatales – ce qui serait, pour le coup, un gros changement avec un impact massif en termes de compatibilité.

Dans le même temps, certains ont noté qu’il n’était peut-être pas urgent d’effectuer ce type de modification². Le sujet d’une éventuelle version de PHP 6.x a donc recommencé à surgir : il permettrait de mettre en place, petit à petit, ce type de modifications potentiellement impactantes, tout en ne gelant pas l’arrivée de modifications plus mineures via des versions comme PHP 5.6 et 5.7.

Andrea Faulds a annoncé avoir rédigé la RFC: list() Reference Assignment, qui permettrait d’utiliser une syntaxe de ce type :

$array = [1, 2];
list($a, &$b) = $array;

A la place (comme raccourci, donc) de la syntaxe suivante :

$array = [1, 2];
$a = $array[0];
$b = &$array[1];

Cela aidera sans doute ceux d’entre nous qui travaillent sous Windows : Anatol Belski a annoncé que les builds pour Windows d’extensions PECL étaient maintenant référencés directement depuis les pages de chaque extension (par exemple, pour solr ou pour APC) – et ce pour une centaine d’extensions sur les environs 300 hébergées par PECL.

Benjamin Schneider a proposé d’ajouter une nouvelle exception, InvalidStateException, à l’extension SPL (Guilherme Blanco a répondu qu’elle pourrait être nommée IllegalStateException). Levi Morrison a fait remarquer que la partie exceptions de la SPL n’était pas des plus structurées, et qu’il pourrait être intéressant de mener une réflexion plus approfondie avant d’ajouter une nouvelle classe – il existe d’ailleurs la RFC: SPL Improvements sur le sujet depuis 2011, mais elle introduirait pas mal d’incompatibilités ; une seconde RFC, RFC: SPL Improvements: Exceptions se concentre, elle, sur les exceptions.

De son côté, Lior Kaplan a continué à poster régulièrement ses rapports sur l’état des Pull Requests faites sur le projet PHP.

Daniel Lowrey a quant à lui annoncé avoir rédigé la RFC: TLS Peer Verification. Il n’y a pas vraiment eu de retour autour de cette proposition ni des autres points qu’il évoquait dans son mail ; peut-être sur les prochaines semaines ?

La RFC: Extended keyword support dont j’avais parlé le mois dernier a été ouverte aux votes – et a été rejetée. Il est à noter que plusieurs votants ont expliqué pourquoi avoir voté non – ce qui est une bonne chose.

Yasuo Ohgaki a annoncé avoir rédigé la RFC: Make session_regenerate_id()’s delete_old_session parameter required gracefully, en vue d’améliorer la sécurité des sessions.

Andrea Faulds a implémenté les fonctions apache_request_headers() (aussi aliasée sous le nom plus générique getallheaders()) et apache_response_headers() pour le serveur web de test intégré à PHP. Même si ce serveur web n’est pas Apache, ces deux fonctions permettent de le rapprocher des autres SAPI.

Dmitry Stogov a proposé deux patchs éliminant des copies inutiles de variables dans array_merge() et func_get_args(), rendant par exemple la page d’accueil de Wordpress 2% à 4% plus rapide. Voici deux petites optimisations qui pourraient trouver leur place dès PHP 5.5 ! Dans la foulée, il a aussi proposé un patch qui éliminerait quelques appels au Garbage Collector.

Après le départ d’Anthony Ferrara il y a quelques semaines/mois et le retrait des RFC qu’il avait rédigé, Andrea Faulds a annoncé avoir réouvert la RFC: Constant Scalar Expressions. Peu de réaction pour l’instant, mais peut-être dans les prochaines semaines…

Oh, et pour finir, tant que j’y pense et en sortant un peu du sujet : j’ai profité de ce week-end de trois jours pour lancer une collecte de données, qui devrait me permettre de prochainement publier un article “Statistiques de versions de PHP” – le dernier remontant à janvier, il date un peu, et une mise à jour ne peut que faire du bien !

Et pour finir avec un peu d’auto-publicité : si le sujet vous intéresse, vous pouvez demander à être prévenu lorsque je publierai le livre électronique Développer une Extension PHP sur lequel je travaille régulièrement.

internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.