Ce mois-ci sur internals@php - Mai 2013

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.