Ce mois-ci sur internals@php - Mars 2013

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.

Je suis assez d'accord avec [Sara Golemon](http://news.php.net/php.internals/66661) et [Julien Pauli](http://news.php.net/php.internals/66683) : cette *solution* est *dingue* -- mais plutôt sympa à lire ^^

Considérant les échanges de ces derniers mois autour de la classe `DateTimeImmutable`, et le fait qu'il l'ait commitée sauvagement sans passer par une RFC, la logique [voudrait](http://news.php.net/php.internals/66817) que Derick Rethans annule cet ajout... Je suis curieux de voir ce que cela va donner sur les prochains semaines, maintenant que PHP 5.5 est feature-frozen, cela dit...