Ce premier mois de l’année 2013¹ a été plutôt agité sur internals@, avec 1082 mails – la barre des 1000 mails sur le mois ayant été pour les deux dernières fois franchie en avril 2012 et en juin 2011 ; pas tous les jours, donc.
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 :

• L’idée d’intégrer le cache d’opcodes Zend Optimizer+ à PHP 5.5 est en cours de discussion,
• PHP 5.5 approche de la fin de versions alpha, et pourrait passer en phase de bêta (qui marque la fin de l’ajout/modification de fonctionnalités) début février,
• PHP 5.3 devrait recevoir des correctifs de sécurité pendant un an après la sortie de PHP 5.5 ; après quoi, cette version aura atteint sa fin de vie,
• La RFC sur les accesseurs n’est pas passée,
• Le sujet des annotations est revenu sur le devant de la scène en début de mois ; avant de s’essoufler.

PHP 5.5 approche la bêta ; PHP 5.3 voit sa fin de vie à l’horizon

Pour ce qui est de PHP 5.5, la version alpha3 est sortie le 10 janvier ; et elle a été suivie, deux semaines après, par la version alpha4, publiée le 24 janvier.

En parallèle à la sortie de la 4ème version alpha, David Soria Parra a annoncé que l’alpha4 devrait être la dernière version alpha, et que la prochaine version de ce qui est en train de devenir PHP 5.5 devrait être la beta1, prévue pour le 7 février².

Comme je l’annonçais le mois dernier, le passage en phase de versions bêta marque la fin de l’ajout/modification de fonctionnalités (“feature-freeze”) ; d’ici peu, nous devrions donc être fixés sur l’ensemble des nouveautés qu’apportera PHP 5.5 !

En parallèle, le sujet de la probable prochaine EOL de PHP 5.3 a été relancé par Pierre Joye, qui annonce quelques jours plus tard l’ouverture du vote sur la RFC: Define PHP 5.3 end of life.

Et tout juste en fin de mois, les résultats du vote sont connus : une écrasante majorité (31 votes pour) de votants pense que PHP 5.3 devrait recevoir des correctifs de sécurité (uniquement) pendant un an, à partir de la sortie de PHP 5.5 ; en citant Pierre Joye :

That means PHP 5.3 end of life (no release, no support, etc.) will happen exactly one year after the release of PHP 5.5.0-stable.
The announce of the exact date will be done at the same time than the release announce for PHP 5.5.0.

Autrement dit³ :

Cela signifie que la fin de vie de PHP 5.3 (plus de sortie de version, plus de support, …) aura lieu exactement un an après la publication de PHP 5.5.0-stable.
L’annonce de la date exactement sera faite en même temps que l’annonce de la publication de PHP 5.5.0.

De son côté, Stas Malyshev se demande avec quelle fréquence les mises à jour mineures de PHP (5.4, principalement, ici) devraient être publiée.

Intégration d’un cache d’opcodes au coeur de PHP ?

Intégrer un cache d’opcodes (de manière générale, l’idée tourne souvent autour d’APC) au coeur de PHP est une idée qui revient fréquemment (y compris sur internals@) ; je me souviens d’une conférence organisée par l’AFUP à Lyon en 2007 ou 2008, alors que PHP 5.3 et PHP 6 étaient encore tous deux en plein développement, où j’avais discuté de ce sujet avec un des conférenciers.

Et, presque immanquablement, dès l’annonce de l’approche de la feature-freeze de PHP 5.5, il est de nouveau fait mention de l’idée d’intégrer APC au core de PHP.

APC manque de développeurs, et n’est pas en avance lorsqu’il s’agit de supporter une nouvelle version de PHP

Cela dit, tout n’est pas rose au royaume de l’extension APC qui manque cruellement de développeurs. En citant Rasmus Lerdorf, qui essaye d’expliquer pourquoi aussi peu de développeurs travaillent sur APC :

It is probably the most complicated piece of the entire stack.
It is a an op_array juggler doing a complex dance on a tight rope backwards and blindfolded.
It is essentially multi-threaded in that there are multiple processes all reading and writing the same chunk of memory while dealing with a compiler that spits out context-sensitive op_arrays that were never designed to be cached and executed this way.

Autrement dit :

Il s’agit probablement de la portion la plus compliquée de l’ensemble de la pile.
C’est un jongleur d’op_array effectuant une dance complexe sur une fine cordre, en marche arrière, avec un bandeau sur les yeux.
Ce composant est principalement multi-threadé, puisqu’il gère plusieurs processus qui lisent et écrivent tous depuis le même bloc de mémoire, tout en travaillant avec un compilateur qui génère des listes d’opcodes dépendant du contexte qui n’ont jamais été conçues pour être cachées et exécutées de cette manière.

Cela dit, il est extrêment réaliste, puisque, quelques phrases plus loin, il n’hésite pas à affirmer :

The real issue here is robustness and lag time between a PHP release
and and solid APC release

Soit :

Le vrai problème est la robustesse et le délai entre la sortie d’une version de PHP
et la publication d’une version stable d’APC lui correspondant.

En plus de cela, on peut craindre que les choses n’aillent pas en s’améliorant du côté d’APC dans les prochains mois, puisque qu’il affirme aussi :

One thing I can guarantee is that if we add it to core in its current condition
it will delay 5.5 by 6+ months if not longer.

Ce qui donne à la traduction :

Une chose que je peux garantir est que si nous ajoutons APC au coeur dans son état actuel,
cela repoussera la sortie de PHP 5.5 de 6 mois, voire même plus.

Bien entendu je ne peux qu’acquiesser lorsque Julien Pauli suggère que plus de documentation pourrait aider ; mais si APC est aussi difficile à maintenir que son développeur principal le laisse entendre, j’ai peur que cela ne facilite que peu la prise en main par de nouveaux développeurs…

Cela dit, un peu plus loin dans la conversation, Zeev Suraski indique que le composant Optimizer+ de Zend fonctionne avec PHP 5.4 et 5.5, est gratuit depuis plusieurs années, et qu’il serait envisageable de l’open-sourcer pour qu’il soit intégré au core de PHP (même si, comme pour APC, une partie du code date un peu et n’est pas nécessairement parfaite), et Rasmus Lerdorf semble d’accord avec cette idée, le but premier étant d’apporter une solution de cache d’opcode intégrée à PHP (sous-entendu, quelque soit son origine, que ça vienne de Zend ou de la communauté au départ).

Bien sûr, comme le souligne Anthony Ferrara, il risque d’être difficile de mettre ceci en place (d’autant plus qu’une RFC implique théoriquement un délai minimal de deux semaines) avant la sortie de la version beta1 et le gel de fonctionnalités correspondant ; il serait peut-être alors nécessaire de rajouter une version alpha5, et de décaler la sortie de la beta1 en conséquence.

Intégrer Zend Optimizer+ à PHP ?

Suite aux échanges dont je parlais au-dessus, Zeev Suraski a annoncé en toute fin de mois qu’il avait rédigé une RFC proposant d’intégrer le cache d’opcodes Zend Optimizer+, aujourd’hui closed-source mais gratuit, dans PHP : RFC: Integrating Zend Optimizer+ into the PHP distribution – au passage, il serait rendu open-source par Zend (le processus est déjà en cours, il semblerait).

Les résultats de benchmarks publiés avec la RFC indiquent que Zend Optimizer+ s’en sort plutôt bien au niveau performances (notamment comparé à APC, il ne fait généralement pas “pire”, voire même est “meilleur”) ; et cette extension supporte déjà les nouveautés apportées par PHP 5.5, et a très tôt été disponible pour PHP 5.4 (contrairement au cache d’opcodes APC, qui est le plus “populaire”, et qui a mis fort longtemps avant d’être vraiment compatible avec PHP 5.4).

Quelques voix s’élèvent pour souligner que Zend Optimizer+ ne supporte pas ZTS (Zend Thread Safety – PHP en mode multi-threads), et que c’est un point qui pourrait être considéré comme bloquant ; mais il semblerait que le support de ZTS puisse être re-mis en place sans trop de difficulté – et, dans le contexte d’un serveur Web, ceci n’est problématique que pour les installations de PHP sous Windows, en mode non-FastCGI (la majorité des utilisations de PHP se faisant en mode multi-processus, et pas multi-threads).

Pour résumer brièvement ce que j’indiquais au-dessus pour ceux qui s’interrogent sur la possibilité d’intégrer APC plutôt que O+, en l’état actuel des choses et comme le souligne Rasmus Lerdorf, APC manque cruellement de mainteneurs (il semble y avoir plus de développeurs sur internals qui connaissent les sources de O+, qui n’est pour l’instant pas open-source, que de contributeurs à APC !), ce qui rend d’après lui cette idée non-viable.

Cela dit, quelques autres développeurs ayant travaillé sur APC par le passé ne semblent pas prendre d’un très bon oeil l’intégration d’un autre outil à PHP (surtout jusqu’à présent développé en closed-source, en dehors de php.net) – alors que cela fait des années que l’idée d’intégrer APC au core revient fréquemment sur le tapis.

Intégrer O+ à PHP 5.5 pourrait repousser la sortie de cette future version d’environ deux mois, notamment pour se donner le temps de stabiliser (tester / valider) l’ensemble ; nombreux sont ceux qui considérent qu’un délai supplémentaire de deux mois est acceptable, considérant le gain que représenterait un cache d’opcodes inclu dans le core ; d’autres, néanmoins, trouvent qu’il serait dommage de repousser la sortie de PHP 5.5 pour cela, alors qu’il existe des alternatives ; et enfin, certains ne sont pas contre un délai, mais notent fort justement que repousser une version de PHP pour ajouter une fonctionnalité doit être une exception bien cadrée, et ne pas devenir une habitude.

En réponse, David Soria Parra (co-release-manager pour PHP 5.5) indique qu’une possibilité serait de ne pas retarder la sortie de la première bêta de PHP 5.5, et d’intégrer O+ pour une version bêta ultérieure, même si “bêta” est censée signifier “feature-freeze” ; pour l’instant, cette proposition n’a pas été suivie de retour.

Notons que la discussion s’est étendue aux interactions entre O+ et d’autres extensions proches, en termes de fonctionnement, du coeur de PHP, comme Xdebug ou Zend Guard Decoder, afin de s’assurer que l’intégration de l’une ne constitue pas un problème pour les autres.

Arrivés en fin de mois, les choses en sont là : l’idée d’intégrer Zend Optimizer+ dans le core de PHP est lancée, la RFC est rédigée et les retours sont dans l’ensemble assez positifs, même si cela peut signifier qu’il faille éventuellement repousser la sortie de PHP 5.5 de deux mois. Nous verrons dans les prochaines semaines l’évolution que prendra cette proposition !

ZTS : Zend Thread Safety

Plus ou moins suite à la discussion autour de Zend Optimizer+, qui ne supporte pour l’instant pas ZTS (Zend Thread Safety), Zeev Suraski a demandé pourquoi est-ce que certains développeurs utilisent ZTS – autrement dit, pourquoi est-ce que certains utilisent PHP en mode multi-threads plutôt qu’en mode multi-processus.

Il s’agissait uniquement d’une discussion visant à déterminer l’utilité, aujourd’hui, de ZTS, et pas à arriver à une quelconque décision quant à son avenir – je ne fais donc ici que rapporter quelques éléments d’information :

• Alexey Zakhlestin a fort justement fait remarquer que ZTS est un pré-requis pour des extensions comme pthreads, qui permet justement d’utiliser des threads depuis du code PHP ; il en va de même pour quelques autres extensions, comme la fonctionalité de sandbox de runkit.
• Laruence a répondu que ZTS est important pour les utilisateurs ayant PHP tournant sous IIS ou Apache avec le MPM workers (alors que FastCGI est censé être plus rapide et plus robuste).
• Pierre Joye aimerait bien supprimer tout ce qui est TSRM (Thread Safe Resource Management) et passer à du LTS (Thread Local Storage) ; mais il reste le problème de Windows, où se reposer sur un mode multi-processus est peu efficace. Il estime par ailleurs qu’arrêter de penser à la thread safety serait une grosse erreur
• Johannes Schlüter a fait noter qu’un bug de multi-threading a été reporté quelque chose comme un an après la sortie de PHP 5.4, et que vu l’importance du bug en question, il semblerait que le multi-thread ne soit qu’assez peu testé.
• Indépendamment du coeur de PHP en lui-même, certains composants ne sont pas TS – tout ce qui est locale, par exemple.
• Johannes Schlüter a aussi fait remarquer – et c’est notamment gênant en hébergement mutualisé – qu’il suffit, avec l’implémentation ZTS actuelle, d’un script avec une stack overflow pour tuer un processus entier ; et donc, tous les threads qu’il héberge (tombant en cascade d’autres requêtes exécutées en parallèle). Pour lui, simplifier la base de code (sous-entendu : en supprimant ce qui est TSRM) serait bénéfique, même s’il est possible que supprimer le mode multi-threads puisse avoir un impact négatif sur les performances dans certains cas d’utilisation.
• Bas van Beek a pour sa part apporté un point de vue que l’on rencontre rarement : il utilise PHP en embed dans des applications C/C++ fortement threadées – et donc, pour lui, ZTS est un élément important ; cela dit, Zeev Suraski a répondu qu’il est d’accord sur l’importance de ZTS dans ce type de cas, et que c’est dans le contexte d’un serveur web multi-threadé qu’il posait la question ; néamoins, prêter moins largement attention à ZTS au niveau de l’équipe de développement de PHP signifierait probablement, en cascade, moins d’efforts au niveau des extensions…

RFC et processus de vote

Suite aux votes sur plusieurs RFC et fonctionnalités controversées, Anthony Ferrara s’est posé la question suivante : lors du vote sur une RFC, sur quoi exactement le vote doit-il porter ? Sur l’idée même de la fonctionnalité proposée par la RFC ? Ou sur l’implémentation qui accompagne généralement celle-ci ?

Les réponses sont assez variées, prouvant que chacun interprête les choses à sa façon : Pierre Joye remarque que les votes ne portent que sur des RFC accompagnées de patches (et donc, d’une implémentation), alors que Zeev Suraski souligne qu’il n’est que rarement demandé de voter pour des modifications de code (hors nouvelles fonctionnalités) et que les concepts devraient être plus importants que leurs implémentations. Les deux points de vue ont trouvé echo, pour autant que je puisse en juger.

Dans les faits, aujourd’hui, voter “pour” une RFC signifie accepter que l’implémentation l’accompagnant soit mergée dans la base de code de PHP – et donc, cette implémentation a un poids fort dans la décision. Est-ce quelque chose qui pourrait changer à l’avenir, par exemple avec des RFC votées alors qu’elles n’en sont qu’à la phase d’idée non accompagnée d’une implémentation ?

Quelques jours plus tard, Zeev Suraski remet en question une partie du processus de votes ; en particulier, suite au vote sur la RFC des accesseurs, il note que les votes n’ont pas toujours de durée bien cadrée.

David Soria Parra, pour ne citer qu’un avis, est d’accord sur le principe proposé au-dessus : un vote devrait avoir une date de début et une date de fin clairement définies dès que celui-ci est ouvert.

Anthony Ferrara note que ceux qui ne participent pas à la discussion sur internals@ autour d’une RFC ne devraient pas être autorisés à voter sur ladite RFC – le but étant de tenir compte des avis de ceux qui ont prêté suffisament attention à la RFC pour prendre part aux échanges qui l’ont accompagnés.

Au cours de ces différents échanges, on peut noter que Zeev Suraski est réaliste sur “la communauté” vs “les développeurs” : il fait remarquer, fort justement, que l’immense majorité des utilisateurs de PHP est silencieuse : pour chaque personne inscrite à internals@, il existe un milier de développeurs qui ne suivent pas ce qu’il s’y passe, les discussions qui y ont lieu, et ne participent pas aux décisions qui impactent le langage.

D’ailleurs, Pierre Joye en remet une couche lors qu’il affirme :

I think many of us are purely and simply totally out of sync with our users.
I have no immediate solution but this is something we must solve, now.

Autrement dit, en français :

Je pense que beaucoup d’entre nous sont purement et simplement désynchronisés par rapport à nos utilisateurs.
Je n’ai pas de solution immédiate, mais c’est un problème que nous devons résoudre, maintenant.

Zeev Suraski insiste par la suite sur le fait que PHP est devenu aussi populaire comme langage de programmation “web” sans les fonctionnalités qui lui ont été ajoutées ces dernières années ni celles en cours de débat, et que nombre de développeurs sont tout à fait content sans – en fait, d’après lui, ils seraient même plus content sans ces nouveautés, qui rendent le langage plus complexe qu’il ne l’était à une époque. Et même sur internals@, il n’est pas le seul à être de cet avis.

Ryan McCue apporte le point de vue d’un développeur s’intéressant au développement de WordPress, ce à quoi Larry Garfield répond que ce problème de l’oeuf et de la poule n’est pas sans solution : un effort pour pousser à la migration vers une version plus récente de PHP, tel que le mouvement GoPHP5 d’il y a quelques années, peut être efficace.
Cela dit, si WordPress, en tant qu’application PHP très répandue, commençait dès maintenant à encourager à utiliser PHP 5.3/4 dans ses requirements, cela serait déjà une si bonne chose…

Grosses discussions – sans résultat immédiat – sur les accesseurs, et sur les anotations

Deux séries de discussions et d’échanges, allant jusqu’à la rédaction de RFCs (et même jusqu’à la phase de vote pour certaines d’entre elles), ont eu lieu ce mois-ci, sans qu’aucune nouvelle fonctionnalité ne soit finalement ajoutée à PHP.

Ajouter une fonctionnalité d’accesseurs à PHP ?

Les multiples discussions sur les accesseurs sont sans aucun doute un des gros sujets de ce mois-ci sur internals@ :

Clint Priest travaille depuis plusieurs mois sur la mise en place d’accesseurs de propriétés ; il a annoncé en début de mois que la RFC: Property Accessors Syntax était sur le point d’être soumise aux votes, et demandait donc une relecture finale. Avec plus de 50 mails dans la discussion, c’est un sujet qui a semblé intéresser du monde !

Dans la suite logique des discussions évoquées au-dessus ainsi que de celles de ces derniers mois, Clint Priest a ouvert les votes sur sa proposition tout juste milieu janvier ; il était prévu, si la RFC passait, que cette fonctionnalité soit ajoutée à PHP 5.5.

Dans le fil de discussion, un avis de Rasmus Lerdorf – je ne cite qu’un intervenant et un mail, mais c’est loin d’être le seul qui aurait de quoi être attirer l’attention :

The simple explanation from me is that the ROI isn’t there on this one.
It adds a lot of code complexity for very little return. Yes, it saves a couple of lines of boilerplate code for a few people, but the cost is high in terms of ongoing maintenance and potential issues for opcode caches as well.
If you look at the split in voting you will notice it is pretty much split along the lines of the people who have to maintain this code vs. the people who would like a shiny new feature.

Soit, en français :

L’explication simple pour moi est que le retour sur investissement n’est pas intéressant pour ce point.
Il entraine l’ajout de beaucoup de complexité au code, pour un gain faible en échange. Oui, cela économise quelques lignes de code pour quelques personnes, mais le coût est élevé en termes de maintenance et de problèmes potentiels pour les caches d’opcodes.
Si on jette un coup d’oeil au partage des votes, on remarquera que la séparation se fait à peu près entre les gens qui auraient à maintenir ce code d’une part, et ceux qui voudraient une nouvelle fonctionnalité d’autre part.

(Les choses ne sont pas nécessairement aussi noires ou blanches, mais je trouve intéressante la distinction faite par le créateur du langage entre “les gens qui maintiennent le code” – les développeurs de PHP – et “les gens qui voudraient une nouvelle fonctionnalité” – les utilisateurs de PHP)

En parallèle, Nikita Popov a proposé une syntaxe alternative, et a rédigé la RFC: Alternative typehinting syntax for accessors ; cette proposition semblait rencontrer des avis plutôt positifs, et elle a donc été elle aussi ouverte aux votes – il est intéressant de noter (je crois que c’est la première fois que je vois le cas se produire) que cette RFC concerne un changement non pas sur une fonctionnalité existante de PHP, mais sur une fonctionnalité en cours de vote (et donc, si cette RFC passe, il faudra pour qu’elle soit appliquée que la première passe elle-aussi).

Dans le fil des échanges, on arrive tout de même à de jolies perles, comme, par exemple :

I’m against Accessors as well so if it goes through then I’ll definitely be stopping with PHP5.4
and ensuring that remains available for the rest of my active programming life …
something I wish I’d done now with 5.2!

Soit, après traduction :

Je suis moi aussi opposé aux Accesseurs donc si cette fonctionnalité passe, je m’arrêterai clairement à PHP 5.4
et m’assurerai que cette version reste disponible pour le restant de ma vie de développement actif…
quelque chose que je regrette finalement de ne pas avoir fait avec PHP 5.2 !

Et alors même que les deux RFC pointées plus haut étaient en phase de vote (les “oui” ne devancent que de peu les “non” sur la première, alors que pour passer, il faudrait 2/3 de “oui”), Steve Clay a lancé un nouveau sujet de discussion, où il a essayé d’introduire une nouvelle propostion, qui pourrait être perçue comme plus simple – ce à quoi Clint Priest n’a pu que répondre que, finalement, une des versions précédentes de sa RFC correspondait à peu près à cette nouvelle idée ; et que nombreux ont été ceux à demander les fonctionnalités ajoutées depuis…

Alors que la phase de votes touchait à sa fin, il a semblé que Clint Priest et Nikita Popov abandonnaient, considérant que leurs propositions avaient reçu beaucoup de votes “non” (dans les faits, plus de 20 votes “contre” et plus de 30 votes “pour” ; ce qui est insuffisant, puisqu’une modification du langage demande deux tiers de “pour” pour être acceptée) ; et ce fut confirmé quelques jours plus tard, avec 34 “pour” et 22 “contre”.

Donc, après plusieurs mois d’échanges : pour l’instant, la fonctionnalité d’accesseurs ne sera pas ajoutée à PHP 5.5 – ni à aucune version, tant qu’elle n’aura pas été revue de manière à arriver à un concensus.

Le retour des discussions sur les annotations

Yahav Gindi Bar a relancé le sujet des annotations, en proposant la RFC: Reflection Annotations using the Doc-Comment.

En soit, l’idée des annotations semble appréciée par pas mal de monde (elles sont utilisées par plusieurs “gros” frameworks genre Doctrine / symfony / Zend Framework) ; par contre, la proposition faite ici utilise une syntaxe qui n’est pas compatible avec celle utilisée “ailleurs”.

Comme l’a fait remarquer Pierrick Charron, ce n’est pas tout à fait la première fois que le sujet est abordé : il existe même déjà une première RFC : Annotations in DocBlock ; Clint Priest a aussi pointé vers RFC: Class Metadata, qui avait été proposée en 2010 par Guilherme Blanco… et qui n’était pas passée.

Mais, encore une fois, l’opposition est vocale ; par exemple, Derick Rethans avance que chaque application/framework utilisant ses propres conventions, un parser d’annotations n’a pas sa place dans le core de PHP.
Cependant, ici aussi, d’autres soutiennent qu’utiliser des DocBlocks pour travailler avec des annotations est un hack, et que cette fonctionnalité aurait sa place dans le core.

Enfin, bref ; j’ai l’impression de voir l’histoire se répéter (les échanges se sont étalés sur une grosse centaine de mails, répartis sur trois sujets de discussion principaux), avec d’un côté “les annotations c’est bien, ça devrait être dans le core de PHP”, et de l’autre “les annotations n’ont rien à faire dans le code de PHP”, avec, au milieu de tout ça, quelques remarques sur la séparation documentation/comportement, des interrogations à propos des caches d’opcodes, et des exemples volontairement exagérés pour être illisibles.

Il y a plus de deux ans, en 2010, le camp du “contre” avait remporté une bataille… Cette fois-ci, la discussion s’est essouflée d’elle-même au bout de quelques jours… Mais qui sait, les annotations ne sont pas le premier sujet à revenir régulièrement sur internals@, le sujet avance un petit peu à chaque fois, et peut-être qu’un jour…

De nombreux petits changements et améliorations

Je ne pense pas qu’il soit nécessaire d’écrire des paragraphes entiers à ce sujet, mais puisque cela a fait un peu de bruit : suite aux échanges, parfois houleux, qui ont eu lieu début janvier autour du sujet des annotations, Anthony Ferrara estime que “PHP a besoin d’une vision” : plutôt que de laisser chacun partir dans son coin, développer une fonctionnalité et rédiger la RFC correspondante et les soumettre à un vote, d’après lui, PHP aurait besoin d’une ligne de conduite générale.

Forcément, les avis en réponses divergent en fonction de chacun ; d’aucun sont satisfait du mode de fonctionnement actuel, d’autres préféreraient que PHP reste “simple”, et les derniers voudraient quasiment que toute fonctionnalité imaginée et imaginable soit ajoutée à PHP.

Finalement, il n’est pas ressorti grand chose des échanges qui ont suivi ; la discussion s’est essouflée ; et, tout au moins à court terme, aucun changement n’est visible quant aux processus d’ajout de fonctionnalité à PHP.

Le vote sur la RFC array_column() a enfin été ouvert.

Au départ deux noms de fonctions (array_column() et array_pluck()) étaient proposés ; finalement, seul le premier a été retenu – bien entendu le plus gros de la discussion a porté sur le nom à donner à cette fonction, et non pas sur la fonctionnalité en elle-même.

Avec 29 votes “pour”, et 6 votes “contre”, il semblerait que cette fonction ait de bonnes chances d’être présente dans PHP 5.5 – reste à ce que le code correspondant soit mergé avant le gel des fonctionnalités prévu pour dans quelques jours !

Le vote sur la RFC: Remove calls with incompatible Context, qui avait été rédigée cet été, a été ouvert par Gustavo Lopes en milieu de mois.

Une semaine après, la RFC est passée à l’unanimité (15 votes “pour”, et 0 vote “contre”) ; et le changement devrait être effectif pour PHP 5.5 – notons que malgré le nom de la RFC, il s’agit uniquement, pour PHP 5.5, d’un marquage comme deprecated.

Stas Malyshev a proposé une solution pour sécuriser l’upload de fichier avec ext/cURL, et a rédigé la RFC correspondante : RFC: Fix CURL file uploads.

Pour ceux qui voudraient plus d’explications sur la problématique de sécurité, ce mail de Stas Malyshev peut être une lecture intéressante.

Les votes ont été ouverts le 21 janvier, et devraient donc s’achever dans quelques jours. Les résultats étant plutôt positifs pour l’instant, il y a de fortes chances que la classe CURLFile soit présente dans la prochaine version de PHP.

Suite à une discussion sur reddit autour du Bug #52424, Damian Tylczyński a remis sur le tapis le sujet de l’inconsistence des noms de fonctions fournies par PHP.

C’est un débat qui revient fréquemment (ce n’est pas le seul – et des fois, au bout de plusieurs années, les choses changent ; ça a par exemple été le cas il y a quelques mois pour la déprécation de ext/mysql) sur la mailing-list internals@, entre ceux qui voudraient uniformiser les noms de fonctions (et, des fois, les ordres de paramètres, aussi), et ceux qui rappellent que la compatibilité avec les versions précédentes est une règle importante de PHP.

D’ailleurs, comme le souligne Stas Malyshev, pour ceux d’entre nous qui travaillent avec des bases de code existantes de grande taille, cette uniformisation n’apporterait absolument rien – sinon la nécessité de retoucher et retester des centaines de milliers de lignes de code.

Quelques modifications visant à améliorer les performances de PHP ont été effectuées :

• Autour des manipulation de dates,
• Pour la fonction strtr() ; certains ont exprimé le souhait que ceci soit mergé sur les branches de PHP 5.4 et de PHP 5.5 ; alors que d’autres répondaient qu’il y avait un risque de régression, et qu’il valait mieux garder ce type de nouveauté pour 5.5. Finalement ce point a été mergé sur PHP 5.4.
• Quelques optimisation pour ARM.

Et, pour finir, voici encore quelques points intéressant, même si je n’estime pas utile d’en parler plus en profondeur :

• En début de mois, Gustavo Lopes a annoncé l’ouverture des votes pour la RFC: zend_parse_parameters() improvements ; deux semaines après, avec 9 votes “pour” et 0 vote “contre”, la modification a été mergée vers PHP 5.5.
• Il a aussi annoncé la RFC: send/recvmsg() wrappers in ext/socket ; c’est le genre de cas pour lequel une RFC ne serait à mes yeux pas nécessaire (ajout à une extension PHP d’une fonction présente dans la bibliothèque encapsulée par cette extension), mais il est appréciable de voir le principe des RFC appliqué de manière sérieuse ; quoi qu’il en soit, puisqu’aucun retour (ni positif, ni négatif) n’a été fait, ceci devrait être mergé sur la branche de PHP 5.5 dans les prochains jours.
• ALeX Kazik a parlé d’un patch qu’il a écrit pour permettre de spécifier le répertoire temporaire depuis php.ini ; cet modification semble appréciée, et il y a de bonnes chances pour qu’elle soit appliquée prochainement, ajoutant une nouvelle directive nommée sys_temp_dir.
• “PHP 6” commence à être évoqué pour de futures modifications ;-)
• Stas Malyshev a proposé un correctif pour Bug #63462: Magic methods called twice for unset protected properties
• Et pour fini, Nikita Nefedov a lancé une discussion sur une éventuelle intégration des symboles de Ruby ; qui n’a pas rencontré suffisament d’intérêt pour aller plus loin.

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.

Cet article n'est pas tout à fait en avance -- mais une semaine de retard ne devrait pas changer grand chose à son contenu.

Finalement, il semblerait que la `beta1` de PHP 5.5 n'ait pas été publiée le 7 février comme cela avait initialement été prévu ; je n'ai pas l'impression que cela ait été officiellement annoncé, mais j'imagine que c'est lié aux discussion en cours autour de l'éventuelle intégration de Zend Optimizer+ à PHP, qui pourrait décaler le planning de sortie de PHP 5.5.

Les traductions fournies dans cet article sont toutes de moi et peuvent être un peu imprécises ; les citations réelles sont bien entendu les versions en anglais.
<br />Je me suis aussi plusieurs fois accordé la liberté de graisser quelques passages qui me semblaient le mériter.