Ce mois-ci sur internals@php - Juin 2013

Après des mois d’avril et de mai très calmes, voici mon dépilage d’internals@ pour le mois de juin 2013, qui a lui aussi été calme, avec seulement 422 mails.

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) :

Après l’annonce de la publication de la version RC3 le 6 juin, Julien Pauli a annoncé, le 20 juin, la sortie de PHP 5.5.0 !

En parallèle, et comme prévu depuis plusieurs mois, Johannes Schlüter a annoncé qu’il n’y aurait plus de nouveau développement sur la branche PHP 5.3 – et que seuls les problèmes de sécurité pourraient encore être traités. Il est donc temps de commencer à penser à migrer vers PHP 5.4 – ou même, vers PHP 5.5 !

Suite à la sortie de PHP 5.5, qui inclut ext/opcache, Julien Pauli a relancé un appel déjà effectué le mois précédent : il serait vraiment bon que cette fonctionnalité, qui est une des nouveautés de PHP 5.5 attendue depuis des années, soit documentée !

Fin mai, Anthony Ferrara avait lancé une discussion où il proposait qu’une passe de nettoyage soit effectuée dans le code de PHP, autour des types entiers et chaînes de caractères ; cela devrait entrainer beaucoup de changements dans le code de PHP, mais n’avoir que peu d’impact sur le comportement du moteur tel que les utilisateurs le voient. Comme l’a souligné Pierre Joye en réponse, cela fait longtemps que cette idée revient régulièrement, et il serait temps d’agir. Considérant la charge de travail, plusieurs intervenants ont proposé leur aide.

Cela dit, comme l’a rapidement fait remarquer Johannes Schlüter, ce type de modification demande beaucoup de travail (le moteur de PHP représente énormément de code, et il faut pas oublier les extensions), et il n’est pas rare que ce type de projet soit abandonné en cours de route. Et, presque un mois après, je n’ai pas le sentiment que les choses aient réellement avancées.

Joost Koehoorn a annoncé avoir rédigé la RFC: Support for anonymous catches : l’idée est de rendre optionnelle la variable dans le bloc catch d’une exception, voire même d’aller jusqu’à rendre celui-ci complètement anonyme, sans spécifier le type de l’exception attendue.

Dans l’ensemble, les retours ont souligné que ne pas avoir à introduire une variable parfois non utilisée pouvait être intéressant. Mais, en même temps, les modifications proposées pourraient rendre le code moins explicite – d’autant plus que même si la variable d’exception n’est pas nécessairement directement utilisée, elle peut apporter des informations utiles lors d’une phase de debug.

Après quelques jours de débats, je n’ai pas l’impression que les choses aient réellement avancées : ne pas devoir spécifier de variable pourrait être sympa en termes de syntaxe, mais sans plus ; et ne pas devoir spécifier de type d’exception ne semble pas si intéressant… Nous verrons dans les prochaines semaines comment le sujet évolue.

Florin Patan a évoqué l’idée d’ajouter à PHP une notion de retour typé.

Comme l’a rapidement souligné Sherif Ramadan, fixer le type de retour d’une fonction ne colle pas réellement à l’esprit souplement typé de PHP, ni au fait que nombre de fonctions de PHP peuvent retourner plusieurs types différents (par exemple, un entier en cas de succès, et un booléen false en cas d’erreur).

Cela dit, même si l’idée ne serait pas applicable à toutes les fonctions, elle pourrait permettre, dans certains cas, de produire du code plus concis – qui aiderait certains frameworks et applications fortement orientées-objet.

Je suis curieux de voir si cette proposition, qui semble avant tout viser à améliorer la qualité du code, ménera à la rédaction d’une RFC, et ce que celle-ci pourrait donner.

Christian Stoller a évoqué l’idée d’introduire une nouvelle syntaxe permettant à foreach d’itérer sur des tableaux à plusieurs dimensions, sans avoir à imbriquer plusieurs structures foreach ; en somme, au lieu de quelque chose de ce type :

<!-- HIGHLIGHT=php -->
foreach ($array as $key => $innerArray) {
    foreach ($innerArray as $innerKey => $value) {
        // ...
    }
}

il serait proposé d’écrire quelque chose ressemblant à cela :

<!-- HIGHLIGHT=php -->
foreach ($array as $key => $innerArray as $innerKey => $value) {
    // ...
}

Je ne sais pas pourquoi, mais je crois que j’aurais tendance à être assez d’accord avec Yahav Gindi Bar qui avait l’air de trouver cette syntaxe difficilement lisible – en particulier avec plus de niveaux d’imbrications. Ce sentiment est d’ailleurs partagé par d’autres.

En toute fin de mois, Anthony Ferrara a annoncé avoir rédigé la RFC: Structural Type Hinting – ça a été le plus gros sujet de discussion du mois, avec un total de 50 mails en 5 jours.

Quelques explications supplémentaires quant à l’utilité de cette proposition peuvent être trouvées dans ce mail. Une utilité serait, au niveau du type-hinting de paramètres de méthodes, de ne plus dépendre d’un nom d’interface, mais de l’API publiquement exposée – quelque soit l’objet l’exposant. La réponse de Ralph Schindler est intéressante, aussi, d’ailleurs.

Les réactions ont été variées, entre ceux qui ont l’air de trouver la proposition géniale, et ceux qui ont évoqué un risque plus grand de problème en cas de changement d’interface – celle-ci étant vérifiée à l’exécution, et plus à la compilation.

Au bout de quelques jours, la discussion a un peu dégénérée, mais je suis curieux de voir ce que cette proposition est susceptible de donner dans les prochains mois !

Dmitry Stogov a relevé qu’une optimisation apportée à strtr() il y a quelques mois avait un impact négatif vraiment perceptible dans nombre de cas réels – correspondant au pire cas de l’algorithme nouvellement mis en place.

Matteo Beccati a travaillé sur l’extension pdo_pgsql, pour lui ajouter le support de quelques fonctionnalités spécifiques à PostgreSQL.

Gernot Vormayr a rédigé la RFC: Apparmor change_hat functionality for php-fpm. Le sujet n’a pas suscité tellement de réactions (aucun commentaire, et seulement trois votes), mais il semblerait, vu les résultats du vote, que la fonctionnalité soit bien partie pour être inclue dans la prochaine version de PHP (PHP 5.x – peut-être PHP 5.6 donc).

Alors que la fin de vie de PHP 5.3 a été annoncée, le Bug #53437: Crash when using unserialized DatePeriod instance, qui entrainait un plantage, pourrait être corrigé pour PHP 5.3 et 5.4 (il avait déjà été corrigé pour PHP 5.5).

Cela sera particulièrement intéressant pour ceux qui souhaiteraient comprendre le fonctionnement du moteur de PHP et s’intéresser (et même, pourquoi pas, participer) au développement de PHP : Julien Pauli, Anthony Ferrara et Nikita Popov ont annoncé avoir commencé à travailler sur une documentation des composants internes du moteur : PHP Internals Book. Deux chapîtres sont pour l’instant disponibles : Classes and objects, et Hashtables.

Anthony Ferrara a travaillé sur la correction d’un plantage lors de la Garbage Collection dans certains cas un peu extrêmes – correction qui a au passage menée a une optimisation. Comme l’a souligné Rasmus Lerdorf, si une correction de bug mène en plus à un gain de performances, il peut être intéressant de continuer à fouiller !

Une peu dans la même logique, Anthony Ferrara a noté qu’il serait intéressant de désactiver le Garbage Collector lorsque le traitement d’un script PHP est en phase de finalisation : s’il s’exécute à ce moment là (plus précisément, pendant qu’une variable est en cours de suppression), il arrive que PHP plante. Cela dit, comme l’a souligné Stas Malyshev, avant de simplement désactiver le GC, il serait bon de comprendre pourquoi, réellement, ce plantage se produit – plutôt que de masquer le problème.

La RFC: Internal operator overloading and GMP improvements rédigée le mois dernier par Nikita Popov a été soumise aux votes. Ses deux composantes ont été acceptées (avec respectivement 14 et 15 votes pour, et 2 votes contre) ; il deviendra donc possible, à partir de PHP 5.6, de surcharger des opérateurs, pour les classes internes à PHP – et cette possibilité sera désormais exploitée pour l’extension GMP.

Sherif Ramadan a lancé une discussion où il a indiqué qu’il souhaitait permettre aux clefs d’un tableau d’être passées à la fonction de callback invoquée par array_filter(). Pour s’assurer de ne pas introduire de BC-break, une possibilité serait de plutôt ajouter une nouvelle fonction array_filter_keys(), ou, sinon, d’altérer le fonctionnement de array_filter() par le biais d’un troisième paramètre. Nous verrons probablement le résultat de la discussion dans les prochaines semaines.

Même si le mois n’a pas été un des plus agités sur internals@, j’ai l’impression que, maintenant que PHP 5.5 est sorti, de nouvelles (ou pas) idées recommencent à arriver sur le devant de la scène – en somme, l’effort de développement commencerait à se ré-orienter vers la prochaine version du langage ; probablement, PHP 5.6.

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.