Ce mois-ci sur internals@php - Décembre 2012

Pour commencer ce récapitulatif de ce qui m’a semblé être les principaux événements et sujets de discussions sur la mailing-list internals@ en ce mois de décembre 2012, David Soria Parra et Julien Pauli, Release Managers de PHP 5.5, annoncent un planning de sortie pour PHP 5.5.

• Cela commence par une seconde alpha mi-décembre, un mois après la première, (cette version alpha2 a été publiée le 21 décembre)
• Viendront probablement ensuite une alpha3 (qui aurait pu sortir fin décembre ; ça sera plutôt probablement pour début janvier) et peut-être une alpha4 (mi-janvier ?),
• Qui seront suivies de probablement deux versions beta, la phase de beta marquant la fin de l’ajout/modification de fonctionnalités (“feature-freeze”).

Suite à cet enchainement de versions alpha et beta, on peut s’attendre à plusieurs versions RC – ce qui ménerait à une sortie de PHP 5.5.0 pour les environs d’avril 2013 (soit un peu plus d’un an après la sortie de PHP 5.4).

Plus ou moins en parallèle, Johannes Schlüter lance le sujet de la fin de vie de PHP 5.3, PHP 5.3.0 étant sortie en juin 2009, et PHP 5.4.0 ayant été publiée en mars 2012.

La difficulté majeure qui va se poser est la lenteur d’adoption de PHP 5.4 par les distributions Linux ; en particulier par les distributions orientées “entreprise” (RHEL 6.3 n’en n’est qu’à PHP 5.3.3), qui sont très longues à adopter de nouvelles versions, ou par les distributions “LTS”.

Le plus gros des problèmes posés par APC en combinaison avec PHP 5.4, qui ont longtemps empéché/retardé la migration d’un nombre non-négligeable de serveurs/applications devraient être réglés : au maximum, il doit rester des bugs déjà présents avec PHP 5.3 ; en citant Rasmus Lerdorf :

APC is at the point now for 5.4 where I don’t think there are any more
edge cases than we have in 5.3. Neither is perfect, but it is close
enough for the majority of sites.

Notons aussi que “EOL” ne veut pas dire que PHP 5.3 cessera de fonctionner ; et cette version continuera probablement à recevoir des correctifs pour les bugs critiques pendant quelques temps (un an ?).

Je n’ai pas le sentimentant qu’un concensus ait réellement été atteint ; cela dit, plusieurs développeurs souhaitent que PHP 5.3 soit annoncé comme atteignant son EOL lors de la sortie de PHP 5.5, pour ne pas avoir trois versions à maintenir en parallèle (PHP 5.3, PHP 5.4, et PHP 5.5) – et leur argument est somme toute rationnel : autant concentrer les efforts sur le développement de nouvelles fonctionnalités et d’améliorations pour les futures versions du langage, plutôt que de continuer à travailler éternellement sur des versions datant de plusieurs années.

Suite à la RFC et au vote dont je parlais le mois dernier, l’extension ext/mysql sera marquée comme dépréciée dès PHP 5.5.

Cela fait plusieurs années que ext/mysql n’est plus “la” solution qui devrait être utilisée pour interroger une base de données MySQL à partir de PHP, mais un rappel ne peut pas faire de mal ; n’hésitez donc pas à communiquer sur ce point : nous devrions tous utiliser ext/mysqli ou PDO.

Comme le fait remarquer Nikita Nefedov depuis son mail DateTime improvement, de nombreux développeurs ont tendance à traiter un objet DateTime comme étant variable (“mutable”, en anglais), ce qui, techniquement, est le cas ; alors qu’une date est, par nature, immuable (“immutable en anglais”)¹.

En l’état actuel des choses, une classe DateTimeImmutable a été implémentée, correspondant à une date immuable ; cette fonctionnalité n’a pas encore été mergée, et n’est pour l’instant disponible que sur la branche Git immutable-date².

Quelques mois après l’ajout des Generators à PHP 5.5, Nikita Popov propose de leur ajouter une méthode throw() – que l’on peut déjà trouver en Python ou en ECMAScript.

Cette proposition n’ayant pas rencontré d’opposition, elle a été commitée pour PHP 5.5.

Lars Strojny note que le PHP Core (les développeurs de PHP en lui-même) n’a pas une voix au sein du PHP FIG (Framework Interoperability Group), et que c’est quelque chose qu’il pourrait être intéressant de changer : Core liason for PHP FIG.

Dans les grandes lignes (en dehors des écarts sur le rôle du FIG, sur sa légitimité à représenter “tout le monde”, sur le fait qu’il ne constitue pas une autorité universellement reconnue, ou sur l’indentation à 2-4 espaces ou tabulations), le sentiment global est que le PHP Core n’a pas vraiment à influencer la manière dont les applications en PHP sont écrites (en particulier, pour les normes de codages, puisque PHP est écrit en C – alors que les applications PHP, elles, sont écrites, de toute évidence, en PHP).

En fait, comme le souligne Pierre Joye, il serait peut-être bon que l’inverse se produise, et que plus de développeurs travaillant sur les différentes applications et frameworks développés en PHP s’impliquent sur le développement de PHP en lui-même ; cela aiderait sans aucun doute à synchroniser les besoins des uns avec l’orientation que prend le langage PHP.

Pierrick Charron a lancé une discussion autour d’ext/curl, suite au changement de comportement de l’option CURLOPT_SSL_VERIFYHOST de libcurl (la bibliothèque que ext/curl expose à PHP) : la valeur 1 n’est plus disponible pour cette option.

En fonction de la version de libcurl utilisée par PHP, désormais, passer la valeur 1 pour l’option CURLOPT_SSL_VERIFYHOST entrainera la levée d’une notice, indiquant :

• soit que valeur est obsolète, et ne sera bientôt plus supportée,
• soit que cette valeur n’est plus supportée, et que 2 sera utilisée à la place.

Donc, potentiellement, il se peut que vous ayiez du code à corriger (et ce dès PHP 5.3) – en particulier si vous aviez considéré que cette option attendait un booléen.

Andrey Andreev propose que les fonctions de manipulation de cookies envoient l’attribut Max-Age dans l’en-tête HTTP Set-Cookie, pour spécifier la durée de vie du cookie, à partir de l’instant présent : Bug #23955: Cookie Max-Age attribute.

Quelques jours après, il a rédigé la RFC correspondante : RFC: Cookie Max-Age attribute.

Les quelques retours (encore peu nombreux, la RFC ayant été rédigée à la toute fin du mois) postés jusqu’à présent ont l’air plutôt positifs.

Victor Berchet propose que plus de structures de données soient implémentée dans PHP. La conversation s’est un peu essoufflée avec la fin d’année ; mais elle a tout de même eu le temps de s’orienter vers la Spl et des différentes classes que celle-ci propose ; classes qui, pour certaines, gagneraient à être retravaillées, d’ailleurs.

Yussuf Khalil propose d’ajouter un modificateur deprecated pour les fonctions et méthodes, et a rédigé la RFC correspondante : RFC: Add a deprecated modifier for functions.

L’idée est que les développeurs d’une bibliothèque ou d’un framework PHP puissent indiquer facilement (et que ce soit exporté via l’API de Reflection, comme c’est le cas pour les fonctions internes à PHP) qu’une fonction/méthode est obsolète, et sera retirée dans une prochaine version.

Dans l’ensemble, les retours sont plutôt opposés à cette proposition, considérant qu’il est difficile/risqué d’ajouter un nouveau modificateur, et qu’appeler trigger_error() au début d’une fonction en levant un avertissement de niveau E_DEPRECATED, tout en ajoutant un tag @deprecated à la phpdoc (pour les IDE notamment), n’est pas une opération complexe pour le développeur de la bibliothèque et permet d’indiquer un message plus précis (comportant par exemple un pointeur vers la solution à utiliser en remplacement).

Bien sûr, comme chaque mois, nous avons droit à quelques correctifs de bugs (par exemple, Bug #52752 : Crash when lexing), ainsi qu’à des améliorations orientées performances ; par exemple pour la fonction date(), ou avec le sujet execute_data->Ts removing.

En parallène, Dmitry Stogov a commencé à travailler sur une refonte de l’implémentation des Traits, l’implémentation courante n’étant pas optimale et se détériorant à chaque correctif, rendant plus difficile la mise en place des suivants. En fonction des retours, ces améliorations pourraient être commitées sur la branche PHP 5.4 dans les prochaines semaines.

Et pour finir sur une note qui serait presque comique (si ce n’était pas en même temps assez triste…), un post de Lester Caine qui note que les choses bougent lentement dans le monde réel ;).

En l’occurence, l’hébergeur 1&1 annonce la fin du support de PHP 4 et de PHP 5.2 pour le 1er avril 2013 – ce qui signifie, oui, qu’ils supportent encore PHP 4 !

Mais aussi, et c’est encore plus surprenant, leur FAQ annonce (je cite) :

To parse a script as PHP 5.4, simply name the script with the file extension .php6

Autrement dit :

Pour qu’un script soit interprété comme du PHP 5.4, il suffit de nommer le fichier avec l’extension .php6.

Arrivés fin 2012 / début 2013, considérant l’histoire de PHP 6, ça laisse songeur, n’est-ce pas ?

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.

Pour plus d'informations sur les objets variables / immuables, vous pouvez consulter :

 * [Objet immuable](http://fr.wikipedia.org/wiki/Objet_immuable) en français, 
 * ou [Immutable object](http://en.wikipedia.org/wiki/Immutable_object) en anglais, 
 * ou encore [Java theory and practice: To mutate or not to mutate?](http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html).

Comme [le souligne](http://news.php.net/php.internals/64372) Pierre Joye, il aurait été intéressant de respecter les processus mis en place, et de rédiger une RFC avant de commencer à implémenter cette nouvelle classe `DateTimeImmuable` sur le repository Git de PHP -- même si elle s'est faite sur une branche séparée...