Ce mois-ci sur internals@php - Septembre 2014

This post is also available in English.

Septembre 2014 a vu 730 messages échangés sur la mailing-list internals@ de PHP, soit quasiment le même nombre qu’en août.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient :

Je disais le mois dernier qu’une mailing-list avait été mise en place pour les membres de l’AFUP, en vue d’échanger en français sur les propositions annoncées sur internals@.

Suite aux discussions que nous avons eu ce mois-ci, j’ai (en tant que coordinateur de celle-ci) posté l’avis de l’AFUP sur trois sujets :

• Notre avis sur la RFC Make defining multiple default cases in a switch a syntax error
• Celui à propos de la RFC Integer Semantics
• Et notre opinion autour de l’ajout de l’opérateur ??

En complément, nous disposons maintenant d’un blog où j’essayerai de poster régulièrement, principalement en français, les opinions que nous avons exprimées sur internals@, ainsi que, dans la mesure du possible, quelques phrases résumant en quoi consistent chaque RFC et pourquoi nous nous sommes exprimés comme nous l’avons fait : PHP Internals en français

Au début du mois, Andrea Faulds a rédigé une RFC nommée “Implicit isset() in Shorthand Ternary Operator”, qui proposait de modifier l’opérateur ?: introduit avec PHP 5.3 pour qu’un isset() soit automatiquement ajouté et, donc, qu’aucune notice ne soit levée.

Les premiers retours ont montré que l’idée pouvait être intéressante, mais, en parallèle, plusieurs voix ont souligné qu’il n’était peut-être pas judicieux de modifier le comportement de l’opérateur ?: de la sorte.

Finalement, cette RFC a été en grande partie ré-écrite, pour arriver à RFC: Null Coalesce Operator, qui proposait d’ajouter un nouvel opérateur ??, au lieu de modifier le comportement de ?:. Ce nouvel opérateur pourrait être utilisé de la manière suivante :

// Utilise $_GET['user'] si existe et 'nobody' sinon
$username = $_GET['user'] ?? 'nobody';

// Charge une donnée depuis le modèle et se rabat sur une valeur par défaut
$model = Model::get($id) ?? $default_model;

Avec 31 votes “pour” et 3 votes “contre”, cette version revue de la RFC est passée et PHP 7 disposera donc d’un nouvel opérateur ??.

Leigh a rédigé la RFC: loop + or control structure, qui propose d’ajouter un bloc, optionnel, aux structures de boucles (for, while, foreach) de PHP. Ce bloc serait exécuté dans le cas où on n’entre jamais dans la boucle (la condition n’étant pas vérifiée, et ce dès le premier passage). Il serait introduit par le mot-clef or.

Avec cette RFC, il deviendrait possible d’écrire quelque chose de ce type :

foreach (generator() as $k => $v) {
    // corps de la boucle
}
or {
    // exécuté si on n'est pas entré
    // dans le corps de la boucle foreach
}

C’est une fonctionnalité qui existe déjà dans certains langages de templating – par exemple, Twig supporte ceci pour ses boucles for, en utilisant le mot-clef else.

Il est à noter qu’utiliser or éviterait d’ajouter un nouveau mot réservé et que le mot-clef else employé par d’autres langage ne semble pas pouvoir être utilisé par PHP, car il mènerait à des ambiguïtés.

Quelques autres idées ont été levées dans la conversation (à voir si quelqu’un les poussera en avant à travers d’autres RFC ?), comme la possibilité qu’une boucle puisse systématiquement retourner le nombre d’itérations effectuées.

Robert Stoll a suggéré que PHP 7 pourrait être l’occasion de rendre les opérations de transtypage plus strictes, de manière à ce que, par exemple, (int)"a" ne vaille plus 0 et lève une erreur. Andrea Faulds a rapidement répondu que les casts explicites ne pouvaient pas échouer et que changer ce comportement maintenant mènerait à une quantité incroyable de bugs et de BC-breaks.

Par contre, une possibilité pourrait être d’ajouter de nouvelles fonctions de transtypage plus strictes – peut-être comme ce que fait déjà ext/filter ? Passer par de nouveaux mot-clefs comme int('2') ou même une syntaxe proche de celle utilisée pour les constructeurs, comme $a = new int('2'), pourrait être une autre approche.

Nikita Popov a rédigé la RFC: Remove alternative PHP tags, qui proposait de supprimer, pour PHP 7, les tags alternatifs <% ... %> et <script language="php"> ... </script>.

Une partie des retours ont été plutôt positifs, mais d’autres ont souligné qu’il serait bon de fournir un script facilitant la migration vers <?php ... ?>.

Les votes ont été ouverts vers la fin du mois et les résultats devraient arriver tout début octobre – les choses semblant plutôt bien parties pour cette RFC pour l’instant.

Levi Morrison a noté que ce qui est généralement appelé type-hints ne sont absolument pas des hints (“hint” se traduisant par “indice” ou “astuce”), puisque les types indiqués lors de déclarations de méthodes et fonctions sont vérifiés et que des erreurs sont levées si les paramètres passés ne correspondent pas à ceux-ci. Il a donc demandé si quelqu’un avait une meilleure proposition de nom, ou s’il fallait rester sur celui-ci.

Andrea Faulds a proposé Optional Type Declarations pour les paramètres et Return Type Declaration pour le type de retour. Ces types n’étant pas optionnels une fois qu’ils ont été positionnés, Type Declarations constituerait un bon compromis – ou peut-être Type Assertions.

D’un autre côté, Type Hints est utilisé depuis des années dans le manuel et par la communauté… Je suis donc curieux de voir si cette proposition aboutira et si on cessera un jour de parler de hints pour quelque chose qui n’en est pas.

Tjerk Meesters a remarqué que les tests de la méthode ReflectionFunction::isDeprecated() dépendent, aujourd’hui, de fonctions marquées comme obsolètes – mais, comme elles pourraient être supprimées de PHP 7, ces tests seront à revoir.

Le test en question pourrait aussi être modifié pour trouver par lui-même une fonction obsolète. Ou, à la place, est-ce qu’il ne serait pas intéressant que PHP définisse une fonction __deprecated__(), qui soit éternellement marquée comme obsolète – quitte à ce qu’elle n’existe que lorsque PHP est compilé en mode debug ?

Dans la conversation, Alexander Lisachenko a noté qu’ajouter un mot-clef deprecated qui puisse être utilisé depuis l’espace utilisateur serait peut-être une alternative intéressante, notamment pour certains gros frameworks. Je me demande d’ailleurs si cette idée n’avait pas déjà été évoquée par le passé…

Dmitry Stogov a rédigé la RFC: Fix list() behavior inconsistency, qui proposait de supprimer quelques inconsistences de list() par rapport aux chaînes de caractères. En effet, aujourd’hui, utiliser list() sur une chaîne de caractères fonctionne ou non selon les cas :

list($a,$b) = "aa"; // $a et $b valent NULL
$a[0]="ab"; list($a,$b) = $a[0]; // $a vaut 'a' et $b vaut 'b'

Pour rendre PHP plus cohérent, cette RFC proposait de complètement interdire l’utilisation de list() sur des chaînes de caractères, ou alors que la rendre possible dans tous les cas. Comme l’a fait remarquer Derick Rethans, la seconde option ajouterait un comportement fonctionnel à PHP, alors que la première reviendrait à supprimer quelque chose qui marche aujourd’hui (même si non documenté).

Les votes ont été ouverts quelques jours avant la fin du mois. Vu l’orientation qu’ils prennent, il est fort probable que quelque chose soit fait, mais il est difficile de prédire laquelle des deux approches sera privilégiée.

Matt Wilmas a travaillé à un patch permettant d’avoir une résolution à la microseconde (avec une bonne précision) pour les fonctions comme microtime(). Il pourrait être intégré pour une prochaine version mineure de PHP 5.6.

Andrea Faulds a ouvert les votes sur la RFC: Scalar Type Hinting With Casts, avant de les mettre en pause pour laisser le temps à plus d’échanges sur le sujet… après lesquels la RFC a été retirée.

Leigh a proposé d’ajouter de nouveaux codes de formats à pack() et unpack(), pour ce qui est 64 bits. La RFC: 64 bit format codes for pack() and unpack() a été rédigée quelques jours plus tard. Cette RFC est passée, avec 15 votes “pour” et 0 vote “contre”.

Voici une autre RFC proposée par Andrea Faulds : RFC: ZPP Failure on Overflow. Elle est partie du constat que, aujourd’hui, lorsqu’un flottant trop grand pour tenir dans les valeurs supportées pour les entiers est passé en paramètre à une fonction interne (fonction exposée par PHP ou par une extension PHP) qui attend un entier, il est reçu par la fonction sous la forme… d’un entier… ce qui entraîne une perte d’information. Cette RFC propose donc que, dans le cas où un paramètre entier est attendu et que la valeur reçue est un flottant trop grand pour tenir dans un entier, l’analyse des paramètres de la fonction interne appelée échoue, que la fonction retourne sans s’exécuter, et qu’un avertissement soit levé.

Au début du mois, Levi Morrison a annoncé l’ouverture des votes sur la RFC: Make defining multiple default cases in a switch a syntax error. Avec 28 votes “pour” et 0 vote “contre”, elle est passée : il ne sera donc plus possible, en PHP 7, d’écrire plusieurs sections default dans un même bloc switch.

En milieu de mois, Andrea Faulds a annoncé l’ouverture des votes sur la RFC: Integer Semantics. Avec 16 votes “pour” et 8 votes “contre”, elle semble être passée – même si les votes ont été clos pas loin d’un jour en avance.

Kris Craig a rédigé la RFC: Change checkdnsrr() $type argument behavior, qui propose de modifier le comportement par défaut de la fonction checkdnsrr() pour charger plus que les informations d’enregistrements MX.

Et enfin, Nicolai Scheer a fait remarquer qu’il n’était pas possible d’utiliser un objet comme clef d’un tableau, même s’il définissait une méthode __toString() : celle-ci n’est pas automatiquement appelée. Appeler automatiquement __toString() dans ce cas de figure ne semble pas optimal, puisque cette méthode est utilisée par certains pour produire une version affichable d’un objet. À la place, une nouvelle méthode magique __toKey() aurait l’avantage de laisser à __toString() le soin de renvoyer une chaîne utilisable pour affichage, alors que cette nouvelle méthode renverrait un identifiant plus technique.

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.