Ce mois-ci sur internals@php - Novembre 2013

le - Lien permanent 8 commentaires

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

Nombres de mails sur internals@ ces trois dernières années


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ée1.


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é2. 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.



  1. PHP 5.5 étant elle-même sortie quelque peu en retard, notamment du fait de l’inclusion de ext/opcache, le “retard” de la phase alpha de PHP 5.6 ne me semble pas encore inquétant

  2. Je me permet de prendre quelques libertés au niveau de l’interprétation et de la formulation ;-) 

Vous avez apprécié cet article ? Faites le savoir !

Commentaires

1. Par Guillaume le 2013-12-04 08:38
Guillaume

Bonjour,

Cela fait deux mois maintenant que je suis les articles “Ce mois-ci sur internals@php” après avoir tenté (en vain malheureusement) de suivre la liste de diffusion directement et je tiens sincèrement à vous remercier pour cette contribution :)

Cela permet d’avoir une visibilité sur ce que pourrait être l’avenir de PHP et pour peu que l’on souhaite se tenir au courant, c’est un “outil” vraiment très pratique! Qui plus est, agréable à lire et bourré de références aux emails permettant de mieux comprendre certains points de vue des contributeurs.

Vraiment, merci!

2. Par Nicolas le 2013-12-04 10:05
Nicolas

Tout pareil que Guillaume, j’ai essayé de suivre la liste de diffusion en vain (principalement par manque de temps) et je dois dire que ce résumé tous les mois est la meilleure source d’information que j’ai trouvée en rapport avec l’avenir de PHP depuis très longtemps. Merci à toi de prendre le temps de le faire!

3. Par Olivier le 2013-12-04 16:33
Olivier

Concernant le dernier point d’Oleg Poludnenko, ça ressemble à une sorte de polymorphisme un peu bâtard non ? Mais dans un langage peu typé comme php, c’est étonnant.

4. Par Pascal MARTIN le 2013-12-04 19:21
Pascal MARTIN

@Guillaume et @Nicolas > merci :-) Content de voir que c’est apprécié !

En fait, pour être franc, avant de faire l’effort de rédiger ces articles, je me disais toujours que “j’allais lire internals@ quand j’aurais le temps”, et j’avais toujours autre chose à faire… Et au final, je ne lisais quasiment jamais ce qu’il s’y passait. Synthétiser ce compte-rendu me “force” à prendre le temps de lire — ce qui est une très bonne chose ^^

@Olivier > ça voudrait aussi dire que deux objets chacun instance d’une classe sœur l’une de l’autre (toutes deux héritant de la même classe mère) ne serait pas vraiment interchangeable l’un-l’autre, si les prototypes de leurs méthodes peuvent être différents de ceux définis par la classe mère. Cette idée ne doit pas tout à faire coller avec le principe de substitution de Liskov.

5. Par Olivier le 2013-12-04 19:38
Olivier

En fait j’avais pas saisi le fait qu’il redéfinissait la fonction au lieu d’en définir une nouvelle avec une signature différente. Je comprends mieux, même si effectivement ça semble farfelu.

Je ne connaissais pas le nom du principe de Liskov, merci de mettre un nom sur un “truc” qu’on connait sans connaitre ;)

6. Par Zéfling le 2013-12-05 02:31
Zéfling

Je découvre ce blog et franchement, c’est très intéressant. J’avais du mal à trouver des informations sur les nouveautés de PHP de façon simple. De plus, les mailing lists, à lire, c’est super chronophage. J’essaie de suivre un peu celle sur le CSS du côté du W3C, je ne me vois pas essayer d’en suivre une autre. En tout cas merci, un résumé parfait.

Bon, peut-être qu’un jour je me motiverais pour proposer des fonctions qui me semblent manquer au langage sur les arrays comme celle-ci.

7. Par Jérémy le 2013-12-05 07:23
Jérémy

Pour ma part j’essaie de la suivre tous les jours, comme ça on ne perd pas trop de temps pour rattraper ça les jours/semaines suivantes.(sauf peut-être les échange un peu trop long ou trop technique)

J’ai cependant été surpris par le nombre d’échange concernant un si simple opérateur que **. Mon avis est qui faudrait soit se ranger du coté des langages qui font de l’associativité à droite soit le rendre non associatif (ce qui pourrait être un plus à PHP pour qu’on ait pas des sources telles que 2 ** 3 ** 99 ** 78 ** 56 ** 56 etc … incompréhensibles)

Il y a encore tant de RFC que j’aimerais voir passer en PHP5.6 : - https://wiki.php.net/rfc/named_params - https://wiki.php.net/rfc/argument_unpacking - https://wiki.php.net/rfc/engine_exceptions - https://wiki.php.net/rfc/expectations - …

Je ne sais pas si c’est moi mais je trouve que la liste des todo est relativement petite !

8. Par Pascal MARTIN le 2013-12-06 13:57
Pascal MARTIN

La todo-list pour PHP 5.6 est effectivement pour l’instant plutôt courte. Elle peut s’allonger avec le temps : après tout, il faut la remplir avant de pouvoir la vider ^^

Le nombre d’échanges autour d’un simple opérateur, ça ne me surprend pas plus que ça : ce n’est pas la première fois qu’un sujet “simple” est longuement débattu.

Lire tous les jours, je n’y arrive pas. J’arrive plus facilement à dégager une demi-journée une fois par mois qu’1/4 d’heure tous les jours — faire 1/4h d’heure sur 10 sujets tous les jours me semble moins “productif” qu’une demi-journée de temps en temps.

Ce post n'est pas ouvert aux nouveaux commentaires (probablement parce qu'il a été publié il y a longtemps).