Ce mois-ci sur internals@php - Juin 2014

This post is also available in English.

Avant de réellement parler de dépilage d’internals@ : vous avez été nombreux à venir me voir tout au long du PHPTour (qui a eu lieu, cette année, les 23 et 24 juin à Lyon) pour me parler de cette série d’articles que je publie depuis maintenant un an et demi, me remercier et m’encourager, en indiquant que cela vous permettait de savoir ce qu’il se passait autour du développement de PHP. Ça fait plaisir et chaud au cœur ; merci à vous tous !

Juin 2014 est redescendu à un volume raisonnable de 493 messages sur la mailing-list internals@ de PHP, après un mois de mai qui avait été animé par plus de 800 mails, dont de longues discussions autour de phpng.

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.6 continue de se rapprocher : le 6 juin, Ferenc Kovacs a annoncé la bêta 4, qui devrait être la dernière version avant la phase de RC.

Et deux semaines plus tard, la première Release Candidate de PHP 5.6 a été publiée !

Comme décidé via la RFC: Define PHP 5.3 end of life, la fin de vie de PHP 5.3 devrait arriver un an après la sortie de PHP 5.5 – qui a eu lieu le 20 juin 2013.

La dernière release corrective de PHP 5.3 ayant été publiée il y a six mois, Stas Malyshev a annoncé qu’une toute dernière version serait publiée prochainement (probablement en juillet) en vue de corriger quelques derniers problèmes.

Ferenc Kovacs a noté qu’il faudrait alors insister sur le fait qu’il n’y aurait ensuite plus de nouvelle version de PHP 5.3 – et qu’il était temps pour tout le monde de migrer vers une version plus récente !

Pierre Joye a indiqué qu’un nouvel outil d’installation d’extensions était en cours de développement : RFC: Pickle.

A moyen/long terme, l’idée est de supprimer la commande pecl de PEAR et que composer soit capable d’utiliser ce nouvel outil pickle pour installer des extensions.

En tout début de mois, Andrea Faulds a rédigé une RFC nommée “Bare Name Array”, qui apporterait deux nouvelles syntaxes, légèrement plus courtes que celles existant aujourd’hui (un peu comme [] est plus court que array()), pour manipuler des tableaux en PHP.

La première permettrait de déclarer des tableaux de la manière suivante, tout en ne changeant pas le comportement actuel de => :

$tableau = [
    clef1: "valeur 1",
    clef2: 42,
    clef3: [
        sub1: 25,
        sub2: "aaa",
    ],
];

Plus loin dans la conversation, Adam Harvey a demandé s’il avait été envisagé d’aller plus loin, en mettant en place quelque chose s’approchant des symboles de Ruby – ce qui ne serait pas évident en PHP, notamment en termes de syntaxe.

La seconde proposition permettrait quant à elle d’accéder aux éléments d’un tableau comme ceci :

echo $tableau:>clef3:>sub2;

Ces deux propositions n’étant pas réellement liées, Levi Morrison a fait remarquer qu’elles devraient être découpées en deux RFC distinctes – et Andrea Faulds les a rapidement créées : RFC: Bare Name Array Literal et RFC: Bare Name Array Dereference.

Les votes sur ces deux RFC ont été ouverts après quelques échanges supplémentaires – et elles ont toutes deux été rejetées (la première avec 14 votes contre et 3 votes pour, et la seconde avec 15 votes contre et aucun vote pour).

Dans l’ensemble, les retours ont principalement insisté sur le fait que ces modifications de syntaxe n’étaient pas nécessaires et rendaient le langage plus complexe – et sur le fait qu’avoir deux syntaxes avec des comportements différents était peu intuitif.

Le mois dernier (en mai, donc), une modification apportée à PHP 5.4.29 et 5.5.13 au niveau de la désérialisation, sur un cas particulier parfois utilisé pour créer des objets sans que le constructeur de la classe correspondante ne soit invoqué (ce qui est un gros hack, surtout sur des classes internes), a entrainé une cassure au sein de briques comme Doctrine ou PHPUnit.

Les deux projets en question ont rapidement été adaptés, mais Jakub Zelenka a souligné qu’il serait bon de sortir rapidement un correctif au niveau de PHP lui-même, que ce soit pour les développeurs ou les autres projets souffrant éventuellement du même problème.

Comme l’a fait remarquer Benjamin Eberlei, si PHP était testé sur une série de projets et bibliothèques (et pas uniquement sur les tests de PHP lui-même) avant chaque nouvelle version, ce type de régression aurait pu être évité¹. Cela dit, comme l’a souligné Johannes Schlüter, il serait utile que les développeurs utilisant PHP prennent la peine de tester un peu plus les versions RCs et de faire des retours – ce qui n’est pas forcément simple et pourrait être facilité si des versions nightly de PHP étaient disponibles sur Travis CI.

La discussion autour de la solution à mettre en place à moyen/long terme a duré quelques temps – alors que Travis CI a appliqué la dernière version de PHP, entrainant des échecs de tests PHPUnit sur plusieurs projets. En même temps, Ferenc Kovacs a insisté sur le fait que sortir un correctif à la hâte n’était pas forcément non plus la meilleure chose à faire.

Au final, une solution basique a été mise en place pour PHP 5.4 et 5.5 de manière à réparer les projets impactés. Une solution plus complète sera mise en place pour PHP 5.6.

Nikita Popov a rédigé la RFC: Uniform Variable Syntax, qui vise à introduire en PHP 6² une syntaxe plus homogène et complète pour les variables.

Bien que la discussion n’ait pas été très longue, les retours ont été plutôt positifs, allant jusqu’à suggérer l’ajout de vérifications dès PHP 5.7 pour détecter les points qui casseront dans le futur.

Pierre Joye a rappelé que la sécurité correspondant à la directive open_basedir pouvait être mise en place en réglant les permissions au niveau du système, que ce soit sous Windows ou sous Linux et que l’effort à fournir pour maintenir celle-ci n’en valait peut-être donc pas la peine. En conséquence, il a proposé de supprimer cette directive pour PHP 6.

Julien Pauli a rapidement répondu qu’elle n’était effectivement plus nécessaire, qu’elle était facile à contourner, et que la supprimer permettrait de nettoyer plusieurs portions du code source de PHP.

Toutefois, même si open_basedir n’apporte pas un réel niveau de sécurité, cette fonctionnalité permet de mitiger le risque d’exploitation de bugs et de les détecter. En fait, pour peu que les développeurs utilisent correctement les flux de PHP et n’affirment pas qu’open_basedir est une directive en lien avec la sécurité, la conserver pourrait être intéressant.

La RFC: Fix handling of custom session handler return values est passée pour PHP 5.7, avec 10 votes “pour” et aucun vote “contre”.

En toute fin de mois, Timm Friebe a annoncé l’ouverture des votes sur la RFC: Catchable “call to a member function of a non-object”. Si cette RFC passe, appeler une méthode sur quelque chose qui n’est pas un objet (comme NULL, par exemple) entrainera la levée d’une E_RECOVERABLE_ERROR à la place d’une erreur fatale.

Andrea Faulds a rédigé la RFC: Big Integer Support, qui propose de continuer à travailler avec des nombres entiers même pour de très grandes valeurs, là où PHP se rabat aujourd’hui sur des nombres flottants lorsque les valeurs manipulées ne tiennent pas dans la plage que les entiers peuvent représenter. Les premiers retours ont été plutôt positifs, même s’il reste des points à éclaircir avant que la RFC ne puisse continuer à avancer sur les prochaines semaines.

David Zuelke a posté quelques corrections qui permettront à php-fpm de mieux fonctionner avec Apache.

Et enfin, alors qu’une RFC sur l’idée de classes anonymes avait été rejetée il y a un moment de cela, Sebastian Bergmann est revenu à la charge sur le sujet, avec un cas où il voit leur utilité (pour la mise en place de tests). Je suis curieux de voir si, cette fois, l’idée ira plus loin – peut-être que PHP 6 pourrait faire pencher la balance dans l’autre sens ?

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.