Ce mois-ci sur internals@php - Novembre 2013

J’ai posté mon premier dépilage d’@internals tout début décembre 2012, en parlant de ce qu’il s’était passé durant le mois de novembre… Cette série d’articles a donc tout juste un an !

Un an après, ce mois de novembre 2013 a poursuivi la tendance à la baisse du nombre de mails entamée le mois dernier, avec 468 messages.

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) :

Continuant à avancer dans le processus de release de la future version de PHP, Ferenc Kovacs a annoncé la création de la branche git correspondant à PHP 5.6.

La todo-list pour PHP 5.6 a été initialisée par Julien Pauli, qui soulignait en parallèle que PHP 5.6 était en retard par rapport au planning de sortie de PHP 5.5 l’an dernier, la première version alpha n’ayant pas encore été publiée¹.

La RFC: Constant Scalar Expressions initialement rédigée par Anthony Ferrara et ré-ouverte par Andrea Faulds le mois dernier correspondait à une idée intéressante, mais que certains trouvaient incomplète, car elle ne permettait pas d’utiliser des constantes dans les définitions.

Pour aller plus loin et résoudre ce point, Bob Weinand a proposé une nouvelle version : RFC: Constant Scalar Expressions. Cette version permettrait d’utiliser des syntaxes de ce type pour déclarer des propriété, en travaillant avec des expressions, incluant éventuellement des constantes :

class Bar {
    public $foo = 1 + 1;
    public $bar = [
        1 + 1,
        1 << 2,
        Foo::BAZ => "foo "."bar"
    ];
    public $baseDir = __DIR__ . "/base";
}

L’idée semblant être appréciée, la RFC a été ouverte aux votes ; et une semaine après, elle est passée, avec 16 votes pour et 2 votes contre. Une nouvelle fonctionnalité pour PHP 5.6, donc !

Tjerk Meesters a annoncé avoir travaillé sur la mise en place d’un nouvel opérateur “**” (qui existe déjà en Python, par exemple) qui agirait comme la fonction pow(). L’idée d’ajouter un opérateur puissance à PHP a semblé en intéresser plusieurs, même si d’autres ont noté qu’il était plus difficile, notamment pour un débutant, de chercher de la documentation sur un opérateur que pour une fonction.

La question de la précédence de cet opérateur s’est rapidement posée : il convient de déterminer ce qu’il doit se passer pour des opérations comme -3 ** 2 ou 2 ** 3 ** 2. Il faudra aussi s’assurer que ce nouvel opérateur est intégré au mécanisme de surcharge d’opérateurs ajouté récemment à PHP, et utilisé à partir de PHP 5.6 pour l’extension GMP. Par soucis de cohérence, l’ajout d’un opérateur **= a également été proposé par Derick Rethans.

Une autre solution évoquée par Pierre Joye, qui éviterait l’ajout d’un opérateur et les questions à propos de sa précédence tout en bénéficiant des mêmes avantages en termes d’optimisation par rapport à l’actuelle fonction pow(), serait de transformer celle-ci en un opérateur – cette idée a déjà été mise en place pour, par exemple, isset(), qui n’est techniquement pas une fonction. Par contre, il ne serait probablement plus possible d’utiliser pow() comme fonction de rappel…

Après quelques jours de discussions, Tjerk Meesters a annoncé avoir rédigé la RFC: Power Operator – les échanges s’étant alors poursuivis sur ce sujet.

Avec 70 mails répartis sur les deux fils de discussions, cette idée de nouvel opérateur “**” a été la plus discutée du mois, et je suis curieux de voir son évolution d’ici le feature-freeze de PHP 5.6 !

Cela faisait quelques temps qu’il travaillait sur ce projet. Joe Watkins a annoncé avoir rédigé la RFC: phpdbg, qui vise à intégrer la plate-forme de debugging phpdbg à PHP.

Parmi ceux qui ont compris ce que représentait cet outil, les retours ont été fort positifs : l’inclusion d’un outil de ce type rendrait PHP plus pratique pour de nombreux développeurs.

Toutefois, les échanges ont montré qu’il était nécessaire que les différences par rapport à d’autres solutions, comme Xdebug, soient plus clairement expliquées – et la RFC a été enrichie en conséquence.

Chris London a noté que la syntaxe elvis de l’opérateur ternaire introduite avec PHP 5.3 souffrait d’un inconvénient : elle entraîne une levée de notice en cas de variable inexistante. Il proposait donc que l’écriture suivante :

$foo = $foo ?: 'default';

devienne équivalente à celle-ci :

$foo = isset($foo) && $foo ? $foo : 'default';

En fait, cette idée n’est pas sans rappeler la proposition, qui remonte à il y a déjà pas mal d’années, de ifsetor()… D’autant plus que la levée de notice est, finalement, une sécurité.

Une idée alternative serait d’introduire un nouvel opérateur ternaire – comme le @: proposé par Mats Lindh – d’autant plus qu’il n’est pas réellement envisageable de modifier le comportement de ?: plusieurs années après sa sortie. Une autre proposition de Philip Sturgeon serait d’écrire ceci :

$foo ||= 'default';

Ou alors, $foo ?= 'default'; qui semble convenir à plusieurs… Bref, plusieurs propositions, mais aucune qui se détache réellement du lot pour l’instant – si tant est que le besoin soit réel, ce que nous verrons (ou pas) sur les prochains mois.

Nikita Popov a fait remarquer que l’idée de ne pas casser la compatibilité antérieure telle qu’elle est formulée dans la RFC: Release Process pouvait parfois être quelque peu contre-productive, chaque changement allant quasi-nécessairement de paire avec… un changement au niveau de la compatibilité². Sa proposition serait de ne plus se limiter à “ça casse la retro-compatibilité, donc non”, et de passer à “ça modifie quelque chose au niveau de la compatibilité, au point de … et sommes-nous d’accord avec cela ?”.

Une des réponses qui a été formulée est que cette promesse de retro-compatibilité n’est déjà plus tellement vraie aujourd’hui. Néanmoins, comme l’a souligné Pierre Joye, cette règle est avant-tout là pour faciliter les montées de versions pour les utilisateurs. En même temps, est-ce que publier une version majeure tous les 8 à 10 ans est toujours acceptable, et ne constitue pas déjà un frein au progrès considérable ?

La réponse de Ferenc Kovacs, considérant son rôle de RM pour PHP 5.6, est intéressante – et montre à quel point il est difficile de trouver un juste milieu, en particulier pour un projet Open-Source comme PHP, qui n’a pas un “dictateur” à sa tête. Comme souligné par Julien Pauli, co-RM de PHP 5.5 et 5.6, il faudrait peut-être commencer à planifier des sorties de versions majeures, et ne plus se concentrer, comme c’est le cas depuis quelques années, sur les versions mineures – et l’idée d’une prochaine version majeure d’ici à trois ans pourrait être une piste.

Suite à des échanges durant depuis quelques temps, Michael Wallner a annoncé avoir rédigé la RFC: Slim POST data, qui vise, à terme, à supprimer la variable HTTP_RAW_POST_DATA – et, en conséquence, à un gain de mémoire.

La rétro-compatibilité étant potentiellement impactée par ce type de modification, Ferenc Kovacs a proposé un plan qui pourrait aider cette fonctionnalité à arriver prochainement, sans pour autant impacter l’existant de manière trop négative.

A suivre le mois prochain, potentiellement, donc.

PHP supporte depuis sa version 5.3 des sections [HOST] et [PATH] dans son fichier de configuration php.ini. Richard Quadling a proposé d’ajouter une section [SAPI=xxx] qui se comporterait de la même manière, mais permettant de spécifier des directives de configuration par SAPI (typiquement, une directive de configuration pourrait avoir une valeur donnée pour PHP exécuté en CLI, une seconde pour PHP en tant que module Apache, une troisième pour php-fpm, …).

Aujourd’hui, nous avons tendance à utiliser un fichier php.ini par SAPI : /etc/php5/apache2/php.ini, /etc/php5/cli/php.ini, /etc/php5/fpm/php.ini, … Cette proposition permettrait de faciliter la mutualisation du plus gros des directives et d’éviter leur duplication.

En dehors de quelques intervenants travaillant sur le packaging de PHP, l’idée n’a pas tellement attiré l’attention, cela dit.

Nikita Nefedov a proposé d’ajouter un troisième paramètre optionnel à array_unique(), afin de permettre de spécifier un callable destiné à comparer les éléments.

Pour garder trace des comportements parfois étranges de PHP lorsqu’il s’agit de comparaisons et de conversions, Yasuo Ohgaki a créé la RFC: Existing comparison and conversion behaviors to discuss/document.

Oleg Poludnenko a évoqué l’idée (étrange ?) de permettre aux méthodes de classes enfants de spécifier des nombres et types de paramètres différents de ceux attendus par la même méthode de la classe parente – voir ce gist pour un exemple de code.

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.