Pascal MARTIN (n+1).zéro

Toutes les fin de mois¹, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou, qui s’en occupe depuis quelques mois :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.

Lors de l’Apéro du 24 juillet 2013, j’ai eu l’occasion de donner une rapide présentation, où j’ai parlé des nouveautés apportées par PHP 5.5, la dernière version stable de notre langage de prédilection, qui a été publiée fin juin.

Les slides que j’ai utilisés comme support sont disponibles en ligne² : PHP 5.5 : slides de ma présentation à l’AperoPHP lyonnais du 24 juillet.

Et puisque j’ai eu plusieurs discussions à ce sujet après la présentation :

• Je publie tous les mois, sur ce blog, une synthèse de la mailing-list internals@ — la mailing-list des développeurs de PHP ; les articles correspondant sont taggés @internals.
• Les articles de mon blog sont bien sûr disponibles via un flux RSS ;-)

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 :

foreach ($array as $key => $innerArray) {
    foreach ($innerArray as $innerKey => $value) {
        // ...
    }
}

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

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.

Après un mois d’avril fort calme, voici mon dépilage d’internals@ pour le mois de mai 2013, qui l’a été tout autant, avec seulement 364 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) :

La sortie de PHP 5.5 continue de se rapprocher : la version RC1 a été annoncée par Julien Pauli le 9 mai, suivie de la RC2 le 24 mai.

En parallèle, puisque PHP 5.5 intégre l’extension ext/opcache qui joue un rôle de cache d’opcodes, mais sans fournir de cache de données, Pierre Schmitz a demandé quelle était la solution à privilégier pour avoir à la fois un cache d’opcodes et un cache de données sur une installation PHP 5.5 — question particulièrement importante pour les packageurs de distributions Linux, dont les choix de configuration impacteront de nombreuses machines. Pour ce qui est du cache de données, plusieurs extensions existent, et aucune ne s’est encore réellement imposée.

Le sujet qui a vu le plus de messages s’échanger ce mois-ci (une soixantaine) a été lancé par Daniel Lowrey, qui regrette de prendre un E_WARNING à chaque fois qu’il utilise des fonctions de manipulation de dates sans avoir configuré la directive date.timezone. Cet avertissement est d’après lui (et il n’est pas le seul de cet avis) particulièrement ennuyeux lorsque PHP est invoqué en ligne de commandes — et potentiellement sans fichier php.ini.

En fait, ce qui est peut-être le plus surprenant est qu’un réglage par défaut entraine une levée d’avertissement — même si, comme l’a indiqué Derick Rethans, celui-ci est là pour signifier qu’il est nécessaire d’effectuer un choix intelligent, que PHP ne peut pas faire seul.

Une solution qui serait envisageable pour certains serait de prendre, par défaut, la timezone du système ; mais, comme l’a indiqué Pierre Joye, ce n’est pas aussi simple, et lorsque PHP essayait de détecter une timezone automatiquement, cette détection échouait souvent. Et comme l’a souligné Paul Reinheimer, il est souvent préférable d’avoir un avertissement plutôt qu’une valeur incorrecte.

Au final, au-delà du fait que PHP ne peut pas détecter une valeur par défaut, plusieurs intervenants estimaient qu’il pourrait être adapté de toujours prendre UTC comme valeur par défaut, mais ce n’est pas une solution pour nombre d’autres. Et après une soixantainte de mails, je n’ai pas le sentiment que les choses aient avancées, que ce soit dans un sens ou dans l’autre.

Thomas Anderson a remis sur le tapis l’idée d’une interface Comparable. Comme l’a fait remarquer Adam Harvey en réponse, l’idée n’est pas nouvelle, et il existe même une RFC — pour peu qu’il y ait des gens intéressés, elle pourrait être dépoussiérée, et re-proposée pour PHP 5.6.

Les premiers retours postés ont cette fois encore semblés plutôt opposés à cette proposition : elle pourrait introduire des cassages de compatibilité, et semble juste inutile à certains. En parallèle, d’autres ont pointé vers des exemples où une fonctionnalité de surcharge d’opérateurs pourrait être intéressante.

La discussion s’est rapidement tassée ; mais considérant que c’est un sujet relativement récurrent, je ne doute pas que nous le verrons revenir un jour ou l’autre. En attendant, certains voudront peut-être jeter un coup d’oeil à l’extension pecl/operator.

Nikita Popov a annoncé avoir rédigé la RFC: Internal operator overloading and GMP improvements, qui propose d’ajouter une surcharge d’opérateurs pour les classes internes à PHP, et implémente cette idée pour GMP.

Je parlais juste au-dessus de l’extension pecl/operator ; son auteur, Sara Golemon, est venue apporter quelques informations à ce sujet de discussion — et Dmitry Stogov a lui aussi indiqué qu’il pourrait être intéressant d’ajouter de nouveaux opcodes, pour gérer au mieux certains cas.

Les échanges qui ont eu lieu étaient tous centrés sur des aspects techniques, et aucun avis ni positif ni négatif n’a réellement été apporté — probablement du fait qu’il s’agit de permettre cette surcharge d’opérateurs uniquement pour des classes internes, et pas pour des classes déclarées depuis du code PHP. A voir si cette RFC ira jusqu’au vote dans les prochaines semaines.

Rouven Weßling a fait remarquer que la gestion de l’UTF-8 par PHP n’était pas vraiment parfaite, et a proposé d’ajouter de nouvelles fonctions à PHP, qu’il a pour l’instant développées sous forme d’une extension. Comme l’a souligné Martin Keckeis, le manque d’un bon support UTF-8 est un sujet récurrent ; auquel nous avons tendance à répondre en utilisant l’extension mbstring.

Nikita Popov a répondu qu’il existait déjà aujourd’hui une quantité non-négligeable de fonctions sachant manipuler de l’UTF-8, et qu’ajouter encore un ensemble supplémentaire de fonctions ne résoudrait pas le vrai problème. En effet, comme l’a noté Adam Harvey, après l’échec de PHP 6, il faudrait peut-être commencer à re-réfléchir à une approche plus globale de la gestion des encodages de caractères pour une prochaine version de PHP.

Richard Lynch a envoyé un mail à propos du fait qu’il faille, dans le constructeur d’une classe fille, appeler manuellement le constructeur de la classe mère ; mais que cet appel échouait et entrainait une Fatal Error dans le cas où la classe mère n’en définissait pas — ce qui, en particulier dans un contexte d’écriture/utilisation de bibliothèques, peut forcer à tester l’existence d’une méthode __construct() avant de l’appeler.

Stas Malyshev a rapidement répondu que, effectivement, il pourrait être intéressant d’améliorer quelque chose à ce niveau ; et qu’une première étape pourrait être la rédaction d’une RFC.

Etienne Kneuss a fait remarquer qu’avoir une classe de base explicite pour toutes les classes pourrait aider à résoudre ce type de problème ; cela pourrait aussi aider lorsque l’on souhaite type-hinter des objets.

La discussion a continué pendant quelques jours, sans qu’aucune décision ne soit pour l’instant prise ; je suis curieux de voir si elle continuera d’évoluer sur les prochaines semaines.

Suite à l’ouverture des sources de Zend Optimizer+ et à son intégration à PHP 5.5 sous le nom d’ext/opcache, il est intéressant de voir des posts comme celui de Terry Ellison, qui a demandé aux développeurs historiques de l’extension s’ils pouvaient jeter un coup d’oeil aux évolutions sur lesquelles il est en train de travailler.

Remi Collet a proposé de permettre à php-fpm de connaitre systemd ; il a ensuite expliqué que ceci permettrait à systemd de présenter des informations à propos du statut du service. La fonctionnalité semble appréciée, mais comme l’a rapidement fait remarquer David Soria Parra, Release Manager de PHP 5.5, cette version a atteint la phase de RC (et donc le feature-freeze correspondant), et cette nouveauté n’aurait pas dûe être intégrée à PHP 5.5.

Suite à une discussion entamée fin avril, Laruence a rérigé la RFC: Add an Second argument to callback of preg_replace_callback. La discussion n’a pas avancé bien loin, mais les retours n’étaient pas franchement positifs.

Bob Weinand a proposé d’ajouter une nouvelle méthode mysqli::bind_value(). Absolument aucun retour n’a été posté sur les plus de vingt jours qui ont suivis — l’idée ne semble pourtant pas mauvaise…

Sebastian Bergmann a fait remarquer que les messages d’erreurs et stacktraces des exceptions indiquent le numéro de ligne où l’objet Exception a été créé, et pas le numéro de la ligne où l’exception a été effectivement levée. Une discussion s’est ensuivie pour essayer de déterminer si ce comportement était le plus intéressant pour l’utilisateur, si utiliser le troisième paramètre du constructeur d’Exception était une bonne solution, s’il fallait ajouter un nouveau mot-clef rethrow au langage, … La discussion s’est un peu essoufflée en fin de mois, sans qu’aucune décision n’ait pour l’instant été prise.

Les votes se sont terminés sur la RFC: instance counter dont j’ai rapidement parlé le mois dernier. Conformément à ce que je pressentais, elle n’est pas passée, avec 14 votes contre, et un seul vote pour. Comme l’ont souligné plusieurs retours, ce type de fonctionnalité a plus sa place dans une extension comme Xdebug que dans le coeur de PHP.

Comme je disais il y a un mois, les choses sont relativement calmes sur internals@ en ce moment, et on ne voit en particulier pas d’ajout de nouvelle fonctionnalité ou de grosse évolution du langage. C’est probablement lié aux faits que PHP 5.5 est actuellement en phase de versions RC (qui signifie qu’il n’est plus possible d’y ajouter de fonctionnalité), et que PHP 5.6 est encore loin et pas encore entré en phase de développement actif — les efforts se concentrant sur les tests et la stabilisation de PHP 5.5.

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.

Après un mois de mars relativement calme, voici mon dépilage d’internals@ pour le mois d’avril 2013, qui poursuit la tendance avec seulement 359 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) :

La sortie de PHP 5.5 continue de se rapprocher : la version bêta3 a été publiée le 11 avril, et la bêta4 a suivi le 25 avril. Cette version bêta4 devrait être la dernière version bêta, la première version RC étant prévue pour le 9 mai.

Dmitry Stogov a travaillé sur des optimisations pour l’extension de cache d’opcodes ext/opcache qui sera inclue à PHP 5.5, et s’est demandé si ces optimisations avaient leur place dans PHP 5.5, ou s’il était plus prudent de les prévoir pour la version suivante de PHP. Une réponse apportée par Zeev Suraski est qu’il devrait être possible de mettre en place des optimisations ne travaillant que sur un seul fichier ; et que certaines idées ne mènent pas forcément à des résultats intéressants, le compilateur de PHP étant relativement rapide en lui-même. Pierre Joye, de son côté, a fait remarquer que, même si des optimisations simples pouvaient être appréciables, les versions RC de PHP 5.5 approchaient.

Comme l’a souligné Larry Garfield, une durée de compilation (compilation qui n’a lieu qu’une fois “de temps en temps”, avec un cache d’opcodes activé) un peu plus importante pour les scripts PHP est acceptable, à partir du moment où les gains à l’exécution ne sont pas négligeables.

Avec l’intégration de ext/opcache à PHP, Johannes Schlüter a fait remarquer qu’il y aurait probablement beaucoup d’utilisateurs qui essayeraient de charger cette extension avec extension= et non zend_extension= dans leurs fichiers de configuration. Le message d’erreur renvoyé lors de la tentative de chargement d’une Zend Extension avec extension= étant jusqu’à présent peu clair, pour éviter d’être submergés de demandes d’utilisateurs ne comprenant pas pourquoi ext/opcache refuse de se charger, il est proposé d’améliorer ce message — vu les nombreux retours positifs, le correctif a été intégré à PHP.

A la toute fin du mois de mars, Laruence a proposé d’ajouter une constante indiquant si PHP est compilé avec support des wrappers curl (qui sont totalement distincts de l’extension ext/curl !). Ces wrappers ayant toujours été considérés comme expérimentaux, la discussion a finalement donné lieu à la rédaction d’une RFC visant à leur suppression : RFC: Removal of curl-wrappers — et même si la décision a été un peu rapide pour rentrer dans la planning de sortie de PHP 5.5-bêta4, les wrappers curl seront supprimés pour PHP 5.5.

En tout début de mois, Sara Golemon a proposé la RFC: PHP Array API simplification : l’objectif est de fournir un fichier d’en-têtes .h permettant de simplifier les manipulations de tableaux PHP pour les développeurs d’extensions PHP (ce point ne concerne que les développeurs d’extensions, et absolument pas les utilisateurs de PHP). Comme l’a souligné Mike Willbanks, avec qui je ne peux être que d’accord, ce type de simplification est le bienvenu, en particulier pour les développeurs avec un background plus userland. La discussion n’a pas duré très longtemps et n’a pour l’instant pas mené à une inclusion de ce fichier d’en-têtes à PHP (peut-être pour une prochaine version ?), mais il peut dès maintenant être inclu manuellement par les développeurs d’extensions qui voudraient en tirer profit.

Un autre point qui peut intéresser les développeurs d’extensions PHP et/ou ceux qui aiment savoir comment ça marche : Julien Pauli a annoncé avoir rédigé un article expliquant comment PHP charge ses extensions, et les différents hooks appelés : internals:extensions. En parallèle, des améliorations sont en cours de développement autour du chargement d’extensions, et pourraient être mises en place pour PHP 5.6.

Laruence a proposé, comme décrit via le Bug #64554: var_export does not export absolute namespace for classname , d’ajouter un \ en début de noms de classes pour les sorties de var_export(), serialize(), et autres fonctions du même type. Certains ont noté que ceci semblait logique par rapport aux espaces de noms ajoutés avec PHP 5.3, alors que d’autres ont fait remarquer que cela casserait la compatibilité avec PHP <= 5.2 — et comme l’a souligné Rasmus Lerdorf, il n’est (malheureusement) pas rare de sérialiser des données avec une version de PHP, les stocker en base de données ou les envoyer via le réseau à une autre machine, et vouloir les lire avec une autre version de PHP. En conclusion, la documentation va être complétée, et le comportement de ces fonctions ne sera pas modifié.

Frank Liepert a rédigé la RFC: instance counter. Les quelques retours qui ont été postés sont assez négatifs : savoir combien d’instances d’une classe donnée existent ne semble pas vraiment intéressant ni utile. Les votes ont été ouverts sur cette RFC à la toute fin du mois — considérant le peu de discussions qu’il y a eu sur internals@ à ce sujet, je doute qu’elle passe.

Julien Pauli a proposé d’ajouter une option à phpinfo(), qui permettrait de récupérer la liste des options de configuration utilisées lors de la compilation de PHP (j’ai au passage découvert php-config --configure-options). Les retours ont été assez négatifs, puisque peu de développeurs voient l’utilité d’un mécanisme de ce type, et suggèrent de plutôt utiliser les capacités de reflection de PHP.

Julien Pauli a soumis une idée où le bloc catch d’une exception pourrait rendre le contrôle à son bloc try. Amaury Bouchard a ensuite fourni plus d’explications sur le pourquoi de cette idée. La discussion n’était pas terminée à la fin du mois, même si plusieurs semblaient penser qu’utiliser des constructions try/catch de cette manière n’était pas une bonne idée. Nous aurons peut-être l’occasion de voir le mois prochain si les choses ont évolué.

Igor Wiedler a annoncé avoir commencé à rédiger la RFC: Importing namespaced functions, et a ensuite posté quelques cas où cette idée lui semble utile. La discussion n’était pas terminée à la fin du mois, et se poursuivra peut-être en mai…

Depuis le premier article que j’ai posté dans cette série de dépilages d’internals@, en novembre 2012, je crois que c’est la première fois que j’ai aussi peu de choses à dire. C’est probablement lié aux faits que PHP 5.5 arrive tout juste à la fin de sa période de bêta, qui marquait la fin d’ajout de fonctionnalités pour cette version, et que PHP 5.6 est encore loin, et pas encore entré en phase de développement actif !

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.

Après un mois de février plutôt chargé, voici mon dépilage d’internals@ pour le mois de mars 2013, qui a été plus calme, avec seulement 497 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) :

Pour résumer de façon très rapide les quelques points principaux :

• PHP 5.5 est passé en phase de beta, avec la beta2 publiée le 28 mars,
• Cette phase de beta signifie la fin de l’ajout de fonctionnalités à PHP 5.5.
• Zend Optimizer+ sera publié avec PHP 5.5, en tant que ext/opcache.

PHP 5.5.0 alpha6 a été publiée le 7 mars ; il était prévu que la version beta1 sorte ce jour-là, mais suite aux discussions encore en cours autour de l’intégration de Zend Optimizer+, il a été décidé de sortir une dernière version alpha.

Le 19 mars, David Soria Parra a annoncé la “Feature Freeze” de PHP 5.5 : plus aucune nouvelle fonctionnalité ne peut être ajoutée à cette version de PHP : les RFC en cours de vote pourront être mergées sur la branche PHP 5.5, mais les futures devront cibler PHP 5.6. Bien sûr, les corrections de bugs sont bienvenues sur PHP 5.5.

PHP 5.5.0 beta1 a été publiée le 21 mars, suivie d’une version beta2 le 28 mars. Il est donc largement temps pour chacun d’entre nous de commencer à tester cette version, pour valider qu’elle n’introduit pas de bug ni de régression pour nos applications ou les bibliothèques et frameworks que nous manipulons tous les jours.

Après avoir lu le fichier UPGRADING de PHP 5.5, Andi Gutmans s’est interrogé sur la fin du support de Windows XP (j’évoquais ce sujet, parmi d’autres, en novembre 2012, dans En route vers PHP 5.5 : Quelques backward-compatible breaks), qui était prévue dès la sortie de PHP 5.4, et a fait remarquer que certains points présentés comme des BC-breaks ne devaient pas avoir d’impact pour les utilisateurs de PHP (s’agissant de points internes) et devraient donc être notés un peu plus loin dans le document, de façon à ne pas décourager ceux qui voudraient migrer vers PHP 5.5.

A propos de Zend Optimizer+, Zeev Suraski a annoncé que la période de votes était terminée, et que 44 votes sur 70 étaient en faveur de l’intégration d’O+ à PHP 5.5 ; il en a profité pour dire que le préfixe des directives de configuration correspondantes serait certainement opcache. ; et qu’il restait à décider si le cache d’opcodes serait ou non activé par défaut.
Je n’entre pas dans les détails, mais la discussion a été un peu houleuse, comme le montrent par exemple ces quelques mails.

En conséquence, le 15 mars, Dmitry Stogov a annoncé qu’il allait merger Zend Optimizer+ vers PHP 5.5, avec, au passage un renommage en ext/opcache — y compris pour les directives de configuration .ini.

En parallèle, plusieurs développeurs ont commencé à utiliser O+ pour le tester, et rapporter des bugs dès maintenant — y compris sous Windows. D’autre part, comme Reeze Xia l’a fait remarquer, il serait bon que O+ continue d’être distribué sous forme de paquet PECL, pour PHP 5.3 et 5.4.

ext/opcache proposant une fonctionnalité de cache d’opcode, mais pas de cache de données utilisateur (contrairement à APC qui proposait les deux), plusieurs extensions sont en cours de développement pour mettre en place un cache de données en mémoire partagée, accessible par les différents processus PHP. Pour l’instant, Laruence a parlé de YAC, et Joe Watkins est parti sur APCu. A voir dans les prochaines semaines comment ces deux extensions évolueront.

Suite à une demande de Fabien Potencier qui souhaitait pouvoir voter sur des RFC, Hannes Magnusson a demandé qui avait le droit de voter sur des RFC : il semblerait que les choses n’aient jamais été très claires à ce niveau.

Tout d’abord, techniquement, il semblerait que n’importe qui ayant le droit de créer une RFC ait aussi le droit de voter.

D’après Pierre Joye, il apparaitrait que les contributeurs à php.net aient le droit de vote (ça ne semble pas surprenant), mais que ce soit aussi le cas pour les responsables reconnus de “projets” (dont la définition n’est pas très claire). Comme l’a souligné Derick Rethans en réponse, cela ne semble pas plus clair comme règle, et il serait bon d’avoir une liste un peu plus stricte de personnes autorisées à voter.

Dans la suite de la conversation, on en est arrivé à des avis qui remettent en question le principe de voter par le biais de RFC, regrettant l’ancienne époque des votes sur la mailing-list — qui permettaient à tout et à chacun de voter, mais qui, en même temps, donnaient peut-être parfois un peu plus de poids à ceux qui participent régulièrement à internals@.

D’ailleurs, la réponse postée par Leigh allait aussi dans le sens “ceux qui participent à internals@ et fixent des bugs devraient avoir plus de poids” — notamment par opposition à ceux qui travaillent uniquement côté userland (donc, ceux qui utilisent PHP). On retombe une fois de plus sur l’opposition développeurs de PHP vs utilisateurs de PHP, fréquemment rencontrée sur internals@.

Derick Rethans a annoncé avoir renommé le fichier NEWS de chaque branche correspondant à une version de PHP, pour qu’ils portent chacun un nom spécifique ; ce afin, à ses yeux, de faciliter les opérations lors de merges entre branches.

Sans attendre, Gustavo Lopes a fait remarquer que cela ne résolvait aucun “problème”, et qu’une solution était déjà connue et documentée, alors que Stas Malyshev et Pierre Joye faisaient noter qu’il aurait pu être intéressant d’en discuter avant d’effectuer ce renommage sans en parler à personne auparavant.

Finalement, Stas Malyshev a annulé cette modification ; mais il s’agit encore d’un élément qui pousse à croire que certains font un peu ce qu’ils veulent comme ils veulent, indépendamment des processus que les autres essayent de mettre en place…

Bob Weinand a rédigé la RFC: unset(): return bool if the variable has existed, où il proposait que unset() retourne true si la deletion a réussi, et false si elle a échoué (typiquement, s’il n’y avait rien à “unsetter”)

Sans me prononcer sur la fonctionnalité proposée, je dois dire que j’apprécie les échanges de mails qu’il y a eu, et la manière dont la RFC a été enrichie au fur et à mesure de ceux-ci, avec des cas d’usage, des résultats de benchmarks, des informations quant à l’implémentation, …

Cela dit, au bout de quelques jours, il n’y a plus eu aucun mail posté autour du sujet, qui en est à plus de vingt jour sans échange… A voir au cours des prochains mois si les choses évolueront (de toute façon, une nouvelle fonctionnalité comme celle-ci ne risquait pas d’arriver dans PHP 5.5).

Peut-être un peu brutalement, Steve Clay a lancé un sujet de discussion où il semblait qu’il demandait s’il était possible de tuer call_user_func() — il a par la suite reformulé sa question, en indiquant qu’il aurait souhaité que les callables puissent systématiquement être appelées directement, et il a apporté plus de précisions dans ce mail.

En réponse, Nikita Popov a indiqué qu’il existait déjà quelques solutions, notamment pour PHP >= 5.4, alors que Anthony Ferrara faisait remarquer qu’il existait d’autres cas pour lesquels un appel direct n’est pas autorisé, même s’il est possible de tricher avec des syntaxes du type ${'_'.!$_=getCallback()}()¹ — et pour ce second point, Stas Malyshev a indiqué qu’il existait une RFC pour cela : RFC: Function call chaining.

Depuis l’ajout “sauvage” (sans passage par le processus de RFC, et qui plus est, après peu de discussions) il y a quelques mois de la classe DateTimeImmutable, l’idée qu’elle ne fait pas ce qu’elle devrait ou qu’elle ne le fait pas comme elle devrait revient assez souvent sur le devant de la scène, au point que Nikita Popov a fini par proposer que l’ajout de cette classe soit annulé tant qu’il en est encore temps, pour éviter d’ajouter une classe dysfonctionnelle à PHP 5.5. S’est alors posée la question de “comment supprimer une fonctionnalité qui n’est pas passé par une RFC alors qu’elle aurait dû”² ^^

Suite à ces quelques mails, et pour compléter les échanges, Michael Wallner a lancé un sujet de discussion où il a indiqué ne pas être satisfait du fait que DateTimeImmutable hérite de DateTime. Après plusieurs mails partant sur autant d’idées différentes, Pierre Joye a rappelé que la marche à suivre était de créer une RFC, ce à quoi plusieurs voix ont répondu que c’était effectivement la chose à faire, mais qu’il ne fallait pas publier DateTimeImmutable telle qu’elle est à présent inclue dans PHP 5.5.

Cela dit, en fin de mois, Derick Rethans semblait refuser d’annuler l’ajout de cette classe DateTimeImmutable. Nous verrons dans les prochaines semaines comment les choses évolueront, si l’architecture de cette classe sera revue, si son ajout sera finalement annulé, ou si elle sortira en l’état…

J’évoquais en février l’idée que certains avaient de réaliser un sondage, pour permettre aux développeurs de PHP de connaitre un peu mieux les besoins de leurs utilisateurs. Paul Reinheimer a continué à travailler sur le sujet, et a proposé une première série de questions.

La bibliothèque PCRE a été montée en version 8.32 sur toutes les branches de développement.

La RFC: PHP CLI changing process title support qui avait été ouverte aux votes le mois dernier est passée, avec 28 votes “pour”, et 1 vote “contre” ; la fonctionnalité a été intégrée à PHP 5.5.

La RFC: Allow non-scalar keys in foreach qui avait été ouverte aux votes en fin de mois dernier est elle aussi passée, avec 21 votes “pour”, et 0 vote “contre”. Suite à cette annonce, quelques échanges ont eu lieu, en particulier entre Nikita Popov, auteur de la RFC et du patch l’accompagnant, et Dmitry Stogov, visant à améliorer ledit patch. La fonctionnalité a été mergée vers PHP 5.5.

Là aussi dans la suite logique de ce que je disais le mois dernier, les votes ont été ouverts sur la RFC: Trailing comma function args. Pour l’instant, les choses semblent relativement mal parties, avec 15 votes “pour” et 20 votes “contre”, alors que la fonctionnalité décrite semblait initialement intéresser du monde — mais comme l’a souligné Sara Golemon, c’est aussi à ça que sert le processus de RFC.

Richard Bradley a lancé l’idée de transformer l’E_ERROR obtenue lors de l’appel d’une méthode sur une variable valant null en E_RECOVERABLE_ERROR, afin que le script PHP ayant provoqué l’erreur puisse l’intercepter et la gérer. Au vu des quelques échanges qui ont suivi, on peut espérer qu’une RFC soit rédigée dans les prochaines semaines.

Stas Malyshev a rédigé la RFC: Secured unserialize(). En réponse, Anthony Ferrara s’est demandé s’il valait mieux essayer de sécuriser le principe de sérialisation/désérialisation, ou s’il était plus judicieux de recommander l’utilisation d’un autre format de données (comme JSON ou XML), interoppérable, lors d’échange d’informations.

Et pour finir, Nikita Popov a commencé à faire une passe sur l’implémentation des Generators de PHP 5.5, et a demandé s’il ne faudrait pas supprimer le support de leur clonage. La seule réponse postée va dans le sens de cette proposition.

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.