Ce mois-ci sur internals@php - Avril 2013

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.