Ce mois-ci sur internals@php - Mars 2014

This post is also available in English.

L’année se poursuit avec un mois de mars 2014 de 611 messages sur la mailing-list internals@ de PHP – ce qui donne un mois plus calme que le précédent, qui était à plus de 950 mails !

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

On sent que le feature-freeze de PHP 5.6 arrive : ce mois-ci n’a vu que peu de mouvement au niveau des RFC et le rythme de nouvelles discussions et idées s’est calmé par rapport aux mois précédents !

En début de mois, le 7 mars, PHP 5.6-alpha3 a été publiée. Il devrait s’agir de la dernière version alpha de PHP 5.6, une première version bêta étant prévue pour la fin du mois de mars¹.

Cette première version bêta correspondra au feature-freeze de PHP 5.6 : plus aucune nouvelle fonctionnalité ou changement ne pourra être intégré pour cette version.

Dans la suite des discussions déjà entamées sur les mois précédents à propos d’une prochaine version majeure de PHP, Julien Pauli a posté une liste de changements qui pourraient / devraient être apportés au moteur de PHP.

Il n’a pas fallu longtemps à Rasmus Lerdorf pour faire remarquer que cette liste était extrêmement ambitieuse (ré-écriture de nombreux composants, y compris parties pas évidentes à prendre en main). Cela dit, comme l’a souligné Pierre Joye, il pourrait être envisageable de traiter au moins une partie de ces points.

Un autre frein à prendre en compte est que seule une petite partie des contributeurs à PHP ont aujourd’hui les connaissances requises pour travailler sur ces points – sans compter qu’il ne faut pas changer trop de choses à la fois !

Heureusement, là où une version mineure ne peut pas casser la compatibilité telle que vue par les utilisateurs du langage, il n’en n’est pas de même pour son fonctionnement interne – ce qui signifie que ces nouveautés pourraient être apportées par PHP 6.1, 6.2, …

Alors qu’il y a déjà eu plusieurs fils de discussion sur le sujet d’Unicode, Rowan Collins a essayé de résumer ce que support d’Unicode signifie.

Il a commencé par rappeler qu’aujourd’hui, une chaîne de caractères PHP n’est en fait qu’une suite d’octets – mais que cette notion ne doit pas disparaître (ne serait-ce que pour représenter des données binaires, comme des images). Il a ensuite demandé quel étaient les réels besoins, en termes de manipulation de texte, pour les utilisateurs – ceux-ci n’étant pas nécessairement liés à la représentation interne d’une chaîne de caractères. Enfin, il a noté qu’il convient de réfléchir à une implémentation qui permette de répondre à ces besoins.

Globalement, la majorité semble d’accord sur le fait que les chaînes devront être représentées, en interne, par un jeu de caractères Unicode. Mais n’oublions pas non plus que Unicode peut en fait correspondre à quatre encodages différents…

Dans le courant de la conversation, une interrogation a été levée : PHP doit-il accepter des identifiants (noms de variables, de fonctions, …) sortant du jeu de caractères ASCII traditionnel ? Considérant la complexité introduite par Unicode, il semblerait pour l’instant que non. Notons tout de même que, aujourd’hui en PHP 5.x, nous ne sommes pas limités à ASCII ;-).

Les discussions se poursuivront probablement pendant encore quelques mois, avant d’arriver à une solution acceptée par le plus grand nombre : sur ce point précis, la prochaine version majeure de PHP est très attendue !

Alors que plusieurs interpréteurs et compilateurs PHP existent (HHVM de Facebook, KittenPHP de Vkontakte, le compilateur vers du bytecode pour la JVM JPJP, HippyVM pour ce qui est Python, …), chacun d’entre eux a tendance à fournir des fonctionnalités qui n’existent pas dans l’interpréteur historique, ou à ne pas implémenter certains des points que celui-ci sait gérer.

En conséquence, Ivan Enderlin a noté que le besoin d’une spécification pour PHP se faisait de plus en plus important – internals@ pouvant être responsable de la rédaction d’un tel standard, de par le poids historique² de cette mailing-list des développeurs de PHP. Ce standard serait une suite logique aux RFC qui ont commencé à structurer le processus d’ajout de fonctionnalités ces dernières années.

Johannes Schlüter a rapidement répondu que tant que PHP était l’implémentation de référence, toute nouvelle fonctionnalité doit être mise en place au sein de celle-ci pour faire partie du langage. Bien sûr, cette réponse est en totale opposition avec l’idée de spécification, où l’implémentation qui respecte celle-ci ne devrait arriver qu’en second.

En face, Andrea Faulds a noté qu’une implémentation de référence n’était pas une réelle spécification, un bug de celle-ci pouvant être considéré comme une fonctionnalité du langage. Et c’est chose qui arrive, puisque la réponse à “qu’est-ce que PHP doit faire ?” est souvent “ce que php-src fait maintenant” !

Une proposition serait d’écrire cette spécification en parallèle du développement de la prochaine version majeure de PHP. De la sorte, celle spécification reflétera la réalité de l’implémentation de PHP 6, tout en fournissant des objectifs pour de futures implémentations.

La discussion s’est calmée en fin de mois. Je suis curieux de voir ce que l’idée donnera dans le futur, en particulier alors que les développements sur PHP 6 commenceront réellement !

Ce mois de mars a vu de nombreuses – et longues – discussions autour de modifications apportées récemment à l’extension de gestion de sessions.

Andrey Andreev a rédigé la RFC: Sessions: Improve original RFC about lazy_write, qui vise à améliorer l’idée précédemment apportée par la RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy.

Julien Pauli a fait remarquer que les deux fonctions session_reset() et session_abort() ajoutées il y a peu ne levaient pas d’erreur en cas de session non initialisée – contrairement aux autres fonctions de gestion de sessions. Ce point devrait être corrigé.

Cela dit, Andrey Andreev a déjà noté plusieurs fois que ces deux fonctions avaient été ajoutées un peu rapidement et n’apportaient pas de réelle valeur ajoutée – et il a donc demandé leur suppression de PHP 5.6, afin de laisser plus de temps de réflexion.

Au bout d’un moment, Julien Pauli est intervenu pour rappeler que le feature-freeze de PHP 5.6 était proche, et qu’il serait possible d’apporter des modifications plus profondes au fonctionnement du module de sessions d’ici la prochaine version majeure de PHP.

Suite à l’acceptation de la RFC: TLS Peer Verification, Chris Wright a proposé un patch qui permet d’obtenir un support de la vérification de peers sous Windows sans avoir à mettre en place de configuration spécifique. Celui-ci visant à grandement faciliter la vie des utilisateurs, il a été accepté.

Comme l’a dit Philip Sturgeon suite au rejet de la RFC: Array Of, une piste pour le futur serait un support de Array of avec une syntaxe de type Generics pour PHP 5.7, suivi d’un réel support complet des Generics pour PHP 6.

Combinant l’ajout du nouvel opérateur de puissance ** et la possibilité d’utiliser des expressions lors de la définition de constantes, Tjerk Meesters a proposé de merger vers PHP 5.6 une Pull-Request permettant d’utiliser ce type de syntaxe :

const FOO = 2 ** 3 ** 2;

Pour finir, Jakub Zelenka a annoncé la création d’un nouveau parser JSON, sous licence PHP (ce qui résoudrait les problèmes évoqués il y a quelques mois), qui apporte un gain non négligeable en performances et en mémoire.

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.