Ce mois-ci sur internals@php - Novembre 2014

Considering how late I am (one entire month…) for this post, I will not take time to translate it in English. Instead, I prefer working on this month’s digest.

Ce post arrive un peu (enfin, un mois…) en retard : j’avais presque terminé sa rédaction, mais les congés de Noël sont passés par là¹. Voici donc, pas tout à fait en avance, mon dépilage de la mailing-list internals@ de PHP pour novembre 2014.

785 messages ont échangés en novembre 2014 sur la mailing-list internals@ de PHP, soit quasiment le même nombre qu’en octobre.

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

Plusieurs changements importants ayant été effectués sur le moteur de PHP pour PHP 7, Andrea Faulds a proposé que le numéro de version du Zend Engine passe de 2 à 3 – ce qui ne semblerait pas choquant, considérant que PHP 7 sera une nouvelle version majeure du langage. La PR correspondante a été mergée début décembre.

La RFC: PHP 7.0 timeline, qui avait été rédigée en octobre, a été soumise aux votes.

Ferenc Kovacs a rappelé que, pour PHP 5.6, le début des versions alpha avait correspondu à la fin d’acceptation de nouvelles propositions et que la phase de versions beta avait été associée à la fin d’ajout de fonctionnalités. Trois mois de stabilisation pourraient être un peu court, considérant le temps qui a été nécessaire pour les versions (mineures) précédentes – c’est aussi pourquoi le cycle de releases annuel s’est en pratique traduit par des versions publiées environ tous les 15 mois.

Dans le courant de la discussion, Kris Craig a noté que la question de la compatibilité antérieure n’avait pas grand chose à voir avec le sujet de la RFC en elle-même et qu’il pourrait être bon d’en parler via un autre sujet, éventuellement accompagné d’un vote. Il a également insisté sur l’idée qu’il pourrait être judicieux de commencer par définir une timeline pour les fonctionnalités qui devraient arriver avec PHP 7, plutôt que de réfléchir en premier à la date de sortie.

Finalement, avec 34 votes “pour” et 2 votes “contre”, cette RFC est passée – et PHP 7 devrait sortir vers mi-octobre 2015.

Alors que PHP 7 avance, Florian Margaine a noté que, même si les BC-breaks sont un mal nécessaire (puisqu’ils permettent de faire évoluer le langage), ils constituent aussi un frein important à l’adoption de nouvelles ou futures versions. Il a donc demandé s’il était envisageable de fixer une sorte de nombre maximal de BC-breaks autorisé pour chaque type de release de PHP.

En restant sur la logique que les versions mineures et patch ne devraient pas intégrer de cassure de compatibilité (sauf, éventuellement, pour combler des failles de sécurité), est-ce que des versions majeures plus fréquentes mais apportant moins d’incompatibilités ne seraient pas une solution ?

Stanislav Malyshev a rédigé la RFC: Default constructors et l’a accompagné d’un blog-post.

Les réponses ont été assez partagées, entre celles plutôt positives qui trouvaient que cela faciliterait les écritures et celles qui soulignaient qu’appeler le constructeur parent sans savoir comment fonctionne la classe parente n’est pas forcément judicieux – même si masquer ce type d’information est un des objectifs de la POO.

Ivan Enderlin a suggéré qu’une approche pourrait être que toute les classes de PHP héritent systématiquement d’une super-classe commune (comme le Object de JAVA), qui disposerait nécessairement d’un constructeur. Mais cela aurait plus d’impacts que ce que cette RFC proposait initialement.

Ce fil de discussion a aussi été l’occasion d’échanger sur le fait que les deux lignes de code suivantes n’entraînent aucun affichage, le paramètre du constructeur inexistant n’étant pas évalué (cf par exemple PHP gotcha 2013 pour une démonstration) :

class Foo {}
new Foo( print('hello') ); 

En restant sur le sujet des constructeurs, Levi Morrison a rédigé la RFC: Remove PHP 4 Constructors, qui propose de supprimer de PHP 7 le support des constructeurs façon PHP 4 (où le constructeur d’une classe était une méthode de même nom que la classe) – ces constructeurs PHP 4 ayant été conservés pour PHP 5, malgré l’ajout de __construct().

En pratique, les constructeurs “PHP 4” ne fonctionnent déjà pas dans tous les cas en PHP 5 : par exemple, ils ne sont pas supportés pour les classes positionnées dans des espaces de noms. Ils sont également ignorés si une méthode __construct() est également déclarée (et encore, ça dépend de l’ordre de déclaration de ces deux méthodes).

Les premiers retours ont été plutôt positifs, même si ce type de changement risque de casser un certain nombre de paquets PEAR (ce serait aussi l’occasion pour ces paquets de se mettre à jour !). Cette rupture de compatibilité semble suffisamment gênante pour que plusieurs soient contre cette proposition.

En pratique, marquer ces vieux constructeurs comme obsolètes pourrait être une première approche, avec une suppression dans une version suivante – on retombe sur la question “y aura-t-il un PHP 5.7 ?”, d’ailleurs.

Les discussions se sont poursuivies autour de la RFC: Safe Casting Functions annoncée le mois dernier : elle a notamment été revue pour tenir compte des retours. Il ne me semble pas que l’idée ait été énoncée précédemment, mais Andrea Faulds a fini par indiquer qu’une proposition comme celle apportée par cette RFC était un pré-requis à une éventuelle mise en place de types plus stricts.

Les votes ont été ouverts en milieu de mois. Finalement, avec 5 votes “pour” et 16 votes “contre”, cette RFC a été rejetée.

Alex Sky a souligné que plusieurs RFCs avaient été rédigées au sujet des annotations et a demandé où les choses en étaient à ce sujet. Chris Wright a rapidement répondu que ces trois RFCs étaient abandonnées (ou rejetées) et qu’il n’y avait aujourd’hui rien de particulier de prévu.

Pierre Joye a enchainé en rappelant que plusieurs gros frameworks ou CMS utilisaient leur propre implémentation en espace-utilisateur et qu’il était peut-être temps d’intégrer ce type de fonctionnalité à PHP lui-même – un peu comme cela a été fait avec la programmation orientée objet il y a quelques années, pour laquelle tout le monde n’était pas nécessairement pour.

Pour éviter de (re-)partir sur un énorme projet Stas Malyshev a suggéré de réfléchir à une approche plus minimaliste que ce qui avait été fait précédemment – ce qui est fait par Doctrine étant trop complexe pour être intégré à PHP.

La discussion s’est poursuivie pendant quelques temps autour, notamment, de problématiques de parsing et de possibilités syntaxiques. Je suis curieux de voir si les choses vont évoluer à ce niveau avant la sortie de PHP 7, d’autant que les avis ont l’air d’être moins opposés à l’idée qu’il y a quelques années…

Andrea Faulds a rédigé la RFC: Unicode Codepoint Escape Syntax, qui propose de permettre l’utilisation de séquences Unicode dans les chaînes de caractères (à double-guillemets et heredoc) de PHP. Par exemple :

$str = "Un caractère unicode : \u{1F602}";

Suite à cette proposition, l’idée a été reprise pour HHVM. En parallèle, Alain Williams a suggéré qu’une syntaxe permettant l’emploi de noms de caractères, comme \U{arabic letter alef}, pourrait aussi être appréciable.

Dmitry Stogov a insisté sur le fait que cette proposition ne fonctionnera que si l’encodage utilisé pour le script et son exécution est UTF-8 – ce qui est fréquemment le cas et serait plus lisible que quelques propositions de syntaxes alternatives.

Sara Golemon a fait remarquer qu’il serait possible d’introduire une syntaxe du type u"une chaine" pour les chaînes Unicode, comme il existe b"une chaine" (qui n’est que très rarement utilisée, mais existe) pour les chaînes binaires – mais il sera temps d’y réfléchir si PHP voit un jour l’apparition de chaînes Unicode. Au passage, inclure ICU pour PHP 7 pourrait être intéressant et faciliter l’inclusion par défaut de UString.

Suite à la RFC: Return Type Declarations, Robert Stoll a remarqué que de plus en plus de propositions visaient à enrichir le type-hinting de PHP… Mais l’information de type n’est pas toujours placée au même endroit : elle est à droite de la fonction dans le cas de type-hinting sur la valeur de retour, alors qu’elle est à gauche des variables dans le cadre des paramètres. Il a donc demandé s’il ne faudrait pas profiter de PHP 7 pour essayer d’uniformiser cela.

Andrea Faulds a répondu que la syntaxe pour le type de retour avait été adoptée comme cela parce que plusieurs étaient opposé à l’idée de mettre le type avant le nom de la fonction – et aussi pour rester cohérent avec la syntaxe choisie plus tôt par Hack. D’un autre côté, Stas Malyshev a souligné que Hack était un autre langage et qu’il n’y avait pas de raison que sa syntaxe pèse bien lourd dans les choix de syntaxes pour PHP.

Levi Morrison a quant à lui fait remarquer qu’il était un peu tard pour lancer cette conversation.

En tout début de mois, Chris Wright a annoncé la RFC: Additional Usage for the Splat Operator, qui proposait d’ajouter un cas possible pour l’opérateur ... mis en place par PHP 5.6 pour les fonctions variadiques et l’unpacking d’arguments.

Cette RFC apporterait une syntaxe plus concise et permettrait d’économiser un appel de fonction, puisque la syntaxe suivante :

$arr1 = ['d' => 4, 'e' => 5, 'f' => 6];
$arr2 = ['a' => 1, 'b' => 2, 'c' => 3, ...$arr1];

deviendrait équivalente, en termes de résultats, à celle-ci, que nous utilisons aujourd’hui :

$arr1 = ['d' => 4, 'e' => 5, 'f' => 6];
$arr2 = array_merge(['a' => 1, 'b' => 2, 'c' => 3], $arr1);

Les premiers retours ont semblé être plutôt positifs, même si la syntaxe pourrait dans certains cas porter à confusion et que les différences avec array_merge() et + ne semblent pas claires pour tout le monde.

En début de mois, Levi Morrison a annoncé l’ouverture des votes sur la RFC: Return Type Declarations. Ils ont été annulés quelques jours plus tard, suite à la détection d’un bug dans l’implémentation proposée. Une fois ce problème corrigé, la RFC pourra re-passer en phase de votes. Quelques semaines plus tard, il a envoyé un mail qui inclut trois propositions d’approches.

Andrea Faulds a demandé s’il pourrait être intéressant d’avoir deux votes différents sur certaines RFC : un vote sur le principe de la modification, suivi d’un second sur l’implémentation proposée. Cela permettrait à des idées d’être validées, avant que leurs auteurs n’aient à investir du temps sur leur implémentation. Zeev Suraski a répondu que sans avoir à mettre en place la lourdeur de deux votes, il était déjà possible de discuter sur internals@ des idées avant de commencer à réellement travailler à leur mise en place. Julien Pauli a ajouté qu’avec cette idée, tout le monde voterait +1 pour les idées, mais qu’il n’y aurait pas plus de monde pour bosser sur le développement et la maintenance des fonctionnalités correspondant.

Daniel Ribeiro a proposé de modifier instanceof pour que son opérande de droite puisse être une expression et non plus seulement une chaîne ou une référence constante à une classe. Stas Malyshev a répondu que cette idée poserait problème dans certains cas (nom d’une classe vs contenu d’une constante, par exemple – ce qui se résoud en utilisant des parenthèses) et qu’il était actuellement possible d’utiliser is_a().

Stas Malyshev a ouvert les votes sur la RFC: Filtered unserialize() en tout début de mois. Avec 17 votes “pour” et 6 votes “contre”, elle est passée.

Kévin Dunglas a soumis une PR visant à rendre FILTER_VALIDATE_URL plus strict et plus proche des standards.

Sara Golemon a rédigé la RFC: IntlChar class, qui vise à intégrer quelques fonctionnalités supplémentaires de la bibliothèque ICU – les classes et fonctions existantes de ext/intl reposant déjà sur cette bibliothèque.

Miloslav Hůla a ouvert les votes sur la RFC: Access to aliases definition by reflection. Elle n’a pas vraiment attiré beaucoup de votants, mais, avec 7 “non” et un seul “oui”, il semblerait qu’elle ne soit pas passée.

Alors que la fin du mois approchait, Guilherme Blanco a annoncé la RFC: Static classes, qui permettrait la création de classes ne pouvant contenir que des méthodes statiques – ce qui peut parfois être utile pour regrouper un ensemble de fonctions utilitaires (le nom abstract static, qui avait été proposé au départ, en a surpris plusieurs – le nom de la RFC a donc été modifié).

Enfin, Anatol Belski a rédigé la RFC: Native TLS, qui ne devrait pas avoir d’impact pour les développeurs utilisant PHP – mais simplifiera probablement la vie aux développeurs de PHP et d’extensions.

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.