Ce mois-ci sur internals@php - Août 2014
10 septembre 2014 —This post is also available in English.
Ayant eu un mois d’août assez occupé (et je suis parti en vacances sans réelle connexion Internet, ce qui n’aide pas ^^ ), je n’ai pas réussi à rédiger mon dépilage d’internals@ pour Juillet 2014 dans les temps, d’autant plus que juillet a été chargé. Au lieu de rédiger celui-ci maintenant et de continuer à accumuler du retard pour celui d’août, j’ai choisi de sauter le dépilage de Juillet – et donc de passer directement à celui d’août, que voici.
Août 2014 est revenu à un nombre raisonnable de 700 messages sur la mailing-list internals@ de PHP, après un mois de juillet qui avait été animé, avec 1144 mails.
Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient :
Johannes Schlüter a ouvert ce mois d’août 2014 en annonçant la première Release Candidate de PHP 5.3.29. Et, deux semaines plus tard, il a annoncé la sortie de PHP 5.3.29, qui marque la fin de vie de PHP 5.3 : plus aucune nouvelle version de PHP 5.3 ne devrait être publiée (ce qui signifie aucune correction de bug, ni même de faille de sécurité).
PHP 5.3 ayant atteint sa fin de vie, Jan Ehrhardt a demandé ce qu’il advenait de PHP 5.4. D’après le processus releases, PHP 5.4, sorti en mars 2012, aurait du recevoir des correctifs de bug pendant deux ans. Toutefois, comme l’a souligné Stas Malyshev, il serait raisonnable pour PHP 5.4 de passer en mode “corrections de failles de sécurité uniquement” une fois PHP 5.6 sortie – et il ne serait pas choquant de maintenir deux versions stables (5.4 et 5.5 – ou 5.5 et 5.6) en parallèle.
Quelques jours plus tard, Stas Malyshev a annoncé que PHP 5.4.33 devrait être la dernière version issue de la branche 5.4, sauf correction de failles de sécurité.
En parallèle, en milieu de mois, Ferenc Kovacs a annoncé que la sortie de PHP 5.6 approchait. Et quelques jours plus tard, le 28 août, il a annoncé la sortie de PHP 5.6.0 !
Dans un autre fil de discussion, il a expliqué pourquoi PHP 5.6 était sortie deux mois en retard par rapport au planning initial : plusieurs versions intermédiaires (alpha, beta, RC) ont, pour différentes raisons, pris une ou deux semaines de retard – et le tout cumulé mène à deux mois.
Andrea Faulds a souligné qu’il pourrait être intéressant d’avoir une dernière version 5.x avant la sortie de PHP 7 – ce qui mènerait à PHP 5.7. En effet, PHP 7 étant une nouvelle version majeure, il semblerait probable qu’il faille environ deux ans avant de pouvoir la sortir et elle inclura de nouveaux points majeurs (et quelques cassures de compatibilité).
Une version 5.7 permettrait de faciliter la migration vers PHP 7, typiquement en ajoutant des avertissements d’obsolescence pour les fonctionnalités qui seront profondément modifiées. Cette version intermédiaire pourrait aussi jouer le rôle de solution de repli si PHP 7 venait à être repoussée pour une raison ou une autre. Comme l’a noté Ferenc Kovacs, aucune version mineure n’a pour l’instant été réalisée en moins de un an et il semble difficile d’imaginer qu’une version majeure (incluant plus de changements ayant plus d’impact) puisse être publiée plus rapidement.
Bien sûr, comme l’ont fait remarquer Derick Rethans, Zeev Suraski et plusieurs autres, il pourrait être préférable de consacrer plus d’énergie à PHP 7, plutôt que de diviser l’effort entre deux futures versions. Il ne faudrait pas non plus reproduire ce qui s’est passé avec PHP 6, où les choses ont fini par cesser d’avancer parce que chacun voulait ajouter encore une fonctionnalité.
Alors que la série d’optimisations orientées performances connues sous le nom de phpng était développée sur une branche distincte depuis maintenant plusieurs mois, Zeev Suraski a ouvert les votes, en début de mois, sur la RFC: Move the phpng branch into master, pour déterminer si cette branche allait être mergée vers la branche master de PHP.
Le sujet ayant déjà été (longuement) débattu, la discussion a été cette fois-ci assez brève – même si plusieurs ont souligné que les modifications apportées par cette branche étaient importantes et auraient un impact fort.
Au final, la RFC a été acceptée, avec 47 votes “pour” et 2 votes “contre” : la branche phpng a donc été mergée vers master.
Andrea Faulds a annoncé l’ouverture de deux RFCs en rapport avec les fonctions et la classe Closure :
La première, qui proposait d’ajouter une méthode call() à la classe Closure, permettant de binder à l’appel, n’a pas tellement été discutée. Elle a été ouverte aux votes en milieu de mois et a été acceptée, avec 13 votes “pour” et 0 vote “contre”.
La seconde a généré plus d’échanges : elle proposait d’ajouter à PHP une syntaxe permettant de faire référence à des fonctions (autrement que par leur nom sous forme d’une chaîne de caractères). Comme l’a souligné Stas Malyshev, la syntaxe proposée entre potentiellement en conflit avec le passage par référence, mais l’idée a semblé en intéresser plus d’un.
À la toute fin juillet, Nikita Popov a rédigé la RFC: Abstract syntax tree, qui proposait de mettre en place une structure intermédiaire dans le processus de compilation des scripts PHP.
Cela pourrait permettre de nouvelles syntaxes techniquement impossibles aujourd’hui avec une compilation en une seule passe, et permettrait de supprimer quelques hacks ainsi que de rendre l’implémentation plus claire et plus facile à maintenir. D’ailleurs, l’implémentation proposée corrige déjà certains points de syntaxe (notamment sur yield et list). Cette modification sur la compilation n’a globalement pas d’impact sur l’exécution : les performances ou l’occupation mémoire ne changeront pas. Par contre, l’introduction d’un AST a un impact (amélioration de 10-15% pour les perfs, mais augmentation de la mémoire consommée) sur la compilation.
L’idée a été fort bien reçue et, sans surprise, cette RFC est passée, avec 47 votes “pour” et 0 vote “contre”.
En complément, il pourrait être possible à l’avenir d’exposer l’AST à l’espace utilisateur (pour de l’analyse statique de code, par exemple), ainsi que de permettre à des extensions de se brancher dessus pour intervenir lors de la compilation.
Andrea Faulds a rédigé la RFC: Integer Semantics, qui propose d’améliorer la consistance cross-plateformes des entiers PHP en corrigeant quelques cas dont le comportement n’était pas clairement défini.
Comme l’a fait remarquer Kris Craig, le rôle d’un langage de haut niveau – comme PHP – serait effectivement de masquer les différences de ce type. En effet, même si ces elles avaient un sens lorsque nombre de développeurs venaient du langage C, c’est nettement moins le cas aujourd’hui.
Derick Rethans a rebondi sur le sujet, en notant qu’il fallait être extrêmement prudent avant de casser la compatibilité, y compris pour une future version majeure comme PHP 7. En effet, tout changement qui serait difficile à détecter entraînera de la frustration pour les utilisateurs et freinera l’adoption de cette nouvelle version. Plusieurs intervenants ont confirmé cette pensée, faisant notamment référence aux problèmes de Python 2 et 3 ou à Perl 6. En même temps, une version majeure est définitivement l’occasion d’améliorer le langage.
Sara Golemon a rédigé la RFC: Make defining multiple default cases in a switch a syntax error qui proposait d’interdire l’écriture de plusieurs cas default au sein d’un même bloc switch (en pratique, aujourd’hui, seul le dernier default est pris en compte). Les retours ont été plutôt positifs pour supprimer ce comportement aberrant.
Certains ont suggéré qu’un changement de ce type pourrait être mis en place pour PHP 5.7 – mais ce serait violer le principe qui interdit les cassures de compatibilité sur des versions mineures et ce changement aurait donc plus sa place pour PHP 7, quitte à générer une E_DEPRECATED en 5.7. Au final, Peter Cowburn a demandé si tout ce processus (RFC, discussion sur la mailing-list, votes) n’était pas un peu lourd pour quelque chose qui pourrait être considéré comme n’étant qu’un bug.
Entre temps, les votes avaient été ouverts, avant que plusieurs intervenants ne fassent remarquer que la durée minimale de discussions sur une RFC, avant ouverture des votes, est de deux semaines. Face à ces débats pour ce qui lui semblait n’être qu’une simple correction de bug, Sara Golemon a laissé tomber le sujet. Levi Morrison a repris le sujet en main quelques jours plus tard.
Il est à noter que la détection de cette incohérence fait suite au travail commencé le mois précédent autour d’une spécification pour le langage PHP.
Marc Bennewitz a rédigé la RFC: Binary String Comparison, qui part du constat que le comportement des comparaisons de PHP est parfois surprenant lorsque l’on compare des chaînes de caractères, puisqu’un transtypage est automatiquement appliqué (en somme, la comparaison est non-stricte) et propose donc de modifier le comportement des comparaisons “non-strictes” de chaînes de caractères afin de les rendre strictes.
Bon nombre de retours ont indiqué que modifier ce comportement serait problématique aujourd’hui, puisque cela casserait une fonctionnalité majeure de PHP. Quoi qu’il en soit, considérant les premiers retours, cette RFC ne semble pas vraiment bien partie.
Au tout début du mois, une mailing-list a été mise en place pour les membres de l’AFUP, en vue d’échanger en français sur les propositions annoncées sur internals@.
Suite aux discussions que nous avons eu sur cette mailing-list, j’ai (en tant que coordinateur de celle-ci) posté l’avis de l’AFUP sur trois sujets :
- Notre avis sur la RFC
intdiv() - Notre opinion sur le merge de la branche
phpngversmaster - Et notre avis sur la RFC: Abstract syntax tree
Le souhait que nous avons est d’essayer d’impliquer plus la commauté (par le biais d’un user-group, pour donner un sens officiel) au processus d’évolution du langage. Cette mailing-list et les mails vers internals@ qui en résultent nous semblent constituer un bon premier pas.
Les votes sur la RFC: intdiv() se sont terminés : l’ajout d’un nouvel opérateur de division entière a été rejeté (par 24 “contre” et 5 “pour”) et la solution de repli – l’ajout d’une fonction intdiv() – a été acceptée (avec 28 votes “pour” et 0 vote “contre”).
Pour faciliter le debuggage, Dmitry Stogov a proposé d’ajouter une nouvelle fonction get_resources() qui retournerait la liste de toutes les ressources existantes (en se limitant éventuellement à un type donné). Cette modification a été réalisée quelques jours plus tard – pas besoin d’une RFC pour un ajout simple et précis comme celui-ci.
Michael Wallner a rédigé la RFC: Add pecl_http to core. Pour l’instant, peu de retours sont arrivés, mais Johannes Schlüter a noté qu’il serait intéressant d’uniformiser en utilisant cette implémentation pour les flux HTTP(s) internes et que cette extension soit systématiquement (ou, au moins par défaut) activée.
Après de longs mois, Anatol Belski a annoncé que le patch 64-bits pour les entiers et les longueurs de chaînes de caractères avait (enfin) été mergé.
Dmitry Stogov a mis en place un nouveau gestionnaire de mémoire pour PHP 7. Le sujet n’a que peu été discuté, mais ce gestionnaire semble apporter un gain de performances – même s’il ne serait que relativement faible.
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.
