Ce mois-ci sur internals@php - Janvier 2015

This post should be available in English in a few days.

1468 messages ont échangés en janvier 2015 sur la mailing-list internals@ de PHP, soit quasiment le double des mois précédents – et d’ailleurs plus que tous les mois depuis que j’ai commencé à effectuer ces dépilages¹ ! Voici donc un mois riche en événements, avec beaucoup d’activité autour de PHP 7 !

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

Pour commencer, les votes se sont terminés sur la RFC: PHP 5.7 qui proposait la sortie d’une version 5.7 de PHP qui aurait allongé le support de la branche 5.x et ajouté des avertissements sur les fonctionnalités qui disparaîtront avec l’arrivée de PHP 7. Avec 14 votes “pour” et 19 votes “contre”, elle a été rejetée et nous ne verrons donc pas de version 5.7 de PHP. Bien sûr, si PHP 7 venait à introduire des changements plus importants que ceux actuellement prévus, il sera possible de re-discuter de cette proposition.

François Laupretre a profité de ce fil de discussion pour souligner qu’il était important, pour encourager les développeurs à monter de version, d’inclure des fonctionnalités attirantes dans PHP 7.0, sans attendre 7.1 ou 7.2 qui ne bénéficieront pas de la même exposition. Même chose pour des améliorations orientées sécurité, d’ailleurs.

Rowan Collins a quant à lui souligné qu’il était peu probable de devoir attendre 10 ans pour PHP 8 et que les dix ans entre PHP 5.0 et PHP 7.0 n’ont vu que peu de versions mineures sur leur première moitié – contrairement à ce qui se fait depuis PHP 5.4. Un cycle d’une version majeure tous les cinq ans lui semblerait plus réaliste.

Julien Pauli a indiqué qu’il serait intéressant que les extensions PECL les plus utilisées soient compatibles avec PHP 7 avant la sortie de la première version RC.

En parallèle, Rasmus Lerdorf a donné du travail aux lecteurs de la mailing-list : prendre une application, n’importe laquelle, et la tester sous PHP 7 (en comparant avec PHP 5.6), en vue d’identifier les changements de comportements et bugs qui pourraient faire obstacle à une montée de version pour les utilisateurs finaux. Comme l’a souligné Sebastian Bergmann, c’est encore plus facile pour de nombreux frameworks et bibliothèques, pour lesquels une bonne première étape est de jouer leur suite de tests automatisés. Pour faciliter les choses, Rasmus Lerdorf a fourni une box Vagrant PHP 7.

Plusieurs ont répondu présent et ont identifié plusieurs problèmes dans différentes applications, qui ont été signalés en vue de corrections, soit du côté des applications, soit du côté de PHP, selon les cas. Dan Ackroyd a quant à lui indiqué que l’extension imagick fonctionnait, maintenant, sur PHP 7.

Rasmus Lerdorf a remarqué un changement de comportement suite à une petite optimisation effectuée il y a quelques temps sur les fonctions de tri utilisées par des fonctions comme usort(). Alexey Zakhlestin a en conséquence suggéré qu’il pourrait être intéressant de lever un avertissement E_STRICT si une fonction de comparaison de ce type ne retourne pas une valeur entière – ce qui est incorrect. Le même type de changement a également été remarqué par Pascal Chevrel sur une autre application.

En tout début de mois, Nikita Popov a ouvert les votes sur la RFC: Remove deprecated functionality in PHP 7, qui proposait de supprimer de PHP 7 les fonctionnalités qui étaient marquées comme obsolètes depuis quelques temps. Une fois les votes terminés, l’ensemble des points proposés sont à supprimer et ne devraient donc plus exister pour PHP 7.

Un peu plus tard, Anatol Belski a relancé la discussion autour de la RFC: Removal of dead or not yet PHP7 ported SAPIs and extensions, qui proposait de supprimer de PHP 7 un ensemble de vieilles SAPIs et d’extensions qui semblaient ne plus être maintenues ou reposer sur des bibliothèques qui ne le sont plus elles-mêmes. Dmitry Stogov a souligné qu’il restait quelques extensions qui n’avaient pas encore été converties ou adaptées pour PHP 7. Après avoir été contactés hors-liste, quelques mainteneurs se sont manifestés pour indiquer qu’ils allaient adapter leurs extensions.

Toute fin décembre et en réponse à des demandes exprimées depuis longtemps, Andrea Faulds a rédigé la RFC: Scalar Type Hints, qui proposait d’étendre le mécanisme de type-hints de PHP aux types de données scalaires : entiers, flottants, booléens et chaînes de caractères.

Adam Harvey a rapidement souligné qu’il serait intéressant de lever des avertissements dès PHP 5.7² en cas d’utilisation des mots-clefs correspondant dans des contextes (noms de classes) où cet usage ne serait plus possible avec PHP 7, d’autant plus que certains frameworks incluent des classes de ces noms.

Même s’il s’agit plus de déclarations de types que de type-hints, plusieurs ont indiqué que cette proposition était intéressante et qu’il s’agissait probablement d’une bonne façon de faire, pour ce qui est des type-hints scalaires, en retenant un principe de typage souple.

Toutefois, la première version de cette RFC ne supportait qu’un typage souple, et d’autres voix se sont élevées pour indiquer que privilégier un typage strict serait préférable, ou que les conversions implicites de types n’étaient pas souhaitables. Comme l’a souligné Marcio Almada, la bataille du typage souple ou strict n’est pas nouvelle – peut-être qu’une idée serait de permettre les deux³, avec une syntaxe différente ? Éventuellement, via une autre RFC ?

Suite à ces échanges, en milieu de mois, une version 0.2 de la RFC a été publiée, proposant à la fois un mode de typage souple et un mode de typage strict, configuré par fichier appelant – puisque permettre à chaque fonction de choisir entre l’un ou l’autre serait risqué – ce qui faciliterait également la migration vers du code plus strict.

Robert Stoll a rapidement proposé que l’instruction declare() correspondante pourrait n’être valide qu’en début de fichier, pour lever toute ambiguité et éviter d’avoir des fichiers qui utilisent potentiellement plusieurs modes de typage. D’autres voix se sont exprimées pour souligner qu’avoir deux modes de typage ou les configurer à l’appel n’était pas une bonne approche – même s’il est à noter qu’une fonction recevra systématiquement le type de donnée qu’elle attend. Au final, comme à chaque fois que les sujets du typage et des type-hints scalaires reviennent sur internals@, les avis sont plutôt partagés, avec des opinions fortes et tranchées et de longs débats… et probablement plusieurs personnes réagissant avant d’avoir réellement compris l’intégralité de la proposition.

À propos, si vous souhaitez en savoir plus sur ce que propose cette RFC, j’ai publié sur ce blog, il y a deux semaines, un article intitulé en faveur de la RFC “Scalar Type Hints”.

Les débats se sont calmés après quelques jours assez intenses, mais je n’ai aucun doute sur le fait qu’ils reprendront de plus belle si cette RFC va jusqu’à l’étape de votes !

Au tout début du mois, Levi Morrison a annoncé que les votes allaient bientôt être ré-ouverts sur la RFC: Return Type Declarations – et ils l’ont effectivement été quelques jours plus tard. Cette proposition permettrait de déclarer une fonction (ou méthode) devant retourner un instance d’une classe données de la manière suivante :

function ma_fonction_01($un_param) : DateTime
{
    return new DateTime( ... );
}

Cette RFC a finalement été acceptée pour PHP 7, avec 47 votes pour et 3 votes contre !

Andrea Faulds a relancé la RFC: Combined Comparison (Spaceship) Operator, qui avait été initialisée par Davey Shafik il y a quelques temps. L’idée semble intéressante, mais comme l’a souligné Jordi Boggiano, il serait peut-être bon d’utiliser un nom un peu moins marrant que T_SPACESHIP – qui serait toutefois un nom fréquemment utilisé dans d’autres langages.

En réponse, Nikita Popov a indiqué qu’une fonction, pouvant être passée comme callback, pourrait être plus intéressante qu’un opérateur, ce à quoi il a été répondu qu’un opérateur comme <=> resterait cohérent avec les autres opérateurs de comparaison et n’entraînerait pas de conflit de nom avec une fonction utilisateur.

La mise en place d’un opérateur ayant le même fonctionnement mais en comparaison stricte n’est pas à l’ordre du jour – mais l’idée pourrait revenir sur le tapis dans le futur ;-)

Juan Basso a rédigé la RFC: Preserve Fractional Part in JSON encode, qui visait initialement à modifier json_encode() pour préserver la partie décimale valant 0 des nombres flottants lors de leur encodage en JSON – par exemple, 10.0 serait encodé vers 10.0 et plus vers 10 comme c’est le cas aujourd’hui (les deux possibilités étant valides d’après la norme JSON). Stas Malyshev a répondu que ceci pourrait être fait dès PHP 5.6 via l’ajout d’une option non-activée par défaut, l’activation par défaut pouvant éventuellement venir plus tard.

Les votes ont été ouvert sur cette RFC quelques jours plus tard et elle a été acceptée avec 14 votes “pour” et 0 vote “contre”. Il est à noter que cette modification arrivera sur PHP 5.6.x, ce qui est théoriquement possible pour des fonctionnalités bien ciblées.

Dans une discussion autour de la RFC: Remove PHP 4 Constructors, Matteo Beccati a annoncé qu’il avait commencé à travailler sur un patch à php-cs-fixer qui aiderait lors de migrations de PHP 5.x vers PHP 7.

En revenant au sujet de cette RFC en elle-même, Andrea Faulds a indiqué qu’elle entraînerait une grosse cassure de compatibilité et qu’il vaudrait peut-être mieux se limiter, au moins pour l’instant, à un avertissement lors de l’emploi de constructeurs façon PHP 4. Et comme Florian Margaine l’a souligné, il serait bien que même des applications qui ne sont plus activement développées aujourd’hui fonctionnent sans mal sur PHP 7. Et même si les constructeurs façon PHP 4 ne sont plus mis en avant depuis la sortie de PHP 5, ils n’ont jamais été officiellement marqués comme obsolètes.

Quoi qu’il en soit, avoir deux manières de définir un constructeur, ne se comportant pas toujours de la même façon, n’est pas appréciable !

Benjamin Eberlei a rédigé la RFC: Add PHP files to auto_prepend from extensions, dont l’idée première était de permettre à des extensions PHP (développées en C, donc) de définir des scripts PHP qui seraient exécutés au début de chaque requête service PHP – suite à quoi il deviendrait possible de développer une partie de ces extensions directement en PHP plutôt qu’en C. Cela reviendrait à standardiser quelque chose que plusieurs extensions font aujourd’hui chacune un peu à leur façon.

Sara Golemon a répondu qu’il pourrait être intéressant d’implémenter la notion de fonctions/classes/constantes persistantes, qui éviteraient de recharger du code à chaque requête (ce qui a un coût, même en cas d’utilisation d’un cache d’opcodes).

Une approche pourrait également être d’inclure le code PHP en question directement dans l’extension, au lieu de dépendre de fichiers PHP externes (qui devraient alors être placés au bon endroit, ce qui peut être source d’erreurs). Celle-ci resterait alors composée d’un seul élément, contenant lui-même du code C compilé et du code PHP ne faisant qu’un pour l’utilisateur. En parallèle, Pierre Joye a souligné que le déploiement de fichiers PHP liés à une extension pourrait être géré par l’outil pickle ou directement par les distributions.

Je suis curieux de voir comment les choses évolueront (d’autant plus quelques patchs ont été écrits), considérant qu’il y a ici plusieurs idées : faciliter le développement d’extensions en permettant l’utilisation de PHP au lieu de C pour certaines composantes soit internes à l’extension soit exposées à l’utilisateur, ou bien permettre l’écriture de liens entre code en espace-utilisateur et les fonctionnalités de l’extension. Benjamin Eberlei a d’ailleurs clarifié l’objectif qu’il avait avec cette RFC.

Une refonte de l’API d’extensions étant en cours de réflexion côté HHVM, Sara Golemon a noté qu’il pourrait être intéressant d’arriver à quelque chose de commun entre HHVM et PHP à ce niveau – ce qui permettrait aux extensions qui ne sont pas fortement liées aux moteur de PHP (une majorité d’extensions, a priori) d’être compatibles avec HHVM et vice-versa. Toutefois, Stas Malyshev a souligné qu’il fallait définir clairement les objectifs d’une telle proposition, afin de déterminer si elle fonctionnerait effectivement avec tant d’extensions que cela.

En tout début de mois et après avoir adapté le patch correspondant pour PHP 7, Stas Malyshev a relancé le sujet de la RFC: Skipping optional parameters for functions, qui vise à permettre de sauter des paramètres lors d’appels de fonctions – paramètres qui prendraient alors leur valeur par défaut. Rowan Collins a souligné que l’idée allait plus loin que ne pas savoir quelles sont les valeurs par défaut : il s’agit aussi de ne pas se soucier d’une éventuelle évolution de ces valeurs par défaut.

Nikita Popov a rédigé la RFC: Remove hex support in numeric strings, qui faisait remarquer qu’il était parfois possible d’utiliser des nombres hexadécimaux dans des chaînes de caractères, mais seulement dans certains cas – la correction proposée étant de complètement supprimer cette fonctionnalité pour PHP 7, ce qui permettrait de corriger quelques inconsistences. Cette RFC a ensuite été soumise aux votes, puis acceptée, avec 29 votes pour et 0 vote contre.

Andrea Faulds a corrigé un bug à cause duquel un caractère octal invalide entraînait la fin du parsing du nombre où il était placé – par exemple, $x = 0109 était équivalent à 010, soit 8 – et pas un échec pur et simple. Ce type de cas entraînera, à partir de PHP 7, une remontée d’erreur.

François Laupretre a proposé une solution visant à permettre aux caches d’opcodes de déterminer si une URI donnée est cachable ou non : RFC: Add is_cacheable() stream-wrapper operation. Les quelques retours ont eu l’air plutôt positifs.

Les votes sur la RFC: Objects as hash keys se sont terminés. Avec 26 votes “contre” et 6 votes “pour”, elle a été rejetée.

Sara Golemon a publié les résultats du vote sur la RFC: IntlChar class : avec 14 votes “pour” et 0 vote “contre”, elle est passée et ext/intl s’enrichit en conséquence d’une classe supplémentaire !

Les votes ont été ouvert sur la RFC: Turn gc_collect_cycles into function pointer, qui visait à permettre à des extensions de se brancher sur le Garbage Collector de PHP, en particulier en vue de profiling. Avec 18 votes pour et 0 vote contre, elle a été acceptée.

Les votes ont également été ouvert sur la RFC: Fast Parameter Parsing API, qui proposait de mettre en place un nouveau mode de déclaration de paramètres, plus rapide, pour les fonctions internes à PHP et à ses extensions. Cette proposition a été acceptée, avec 19 votes pour et 1 vote contre.

Yasuo Ohgaki a souligné que le comportement de foreach n’était pas toujours très intuitif et que PHP 7 serait une bonne occasion pour corriger cela. Tout à la fin du mois, Dmitry Stogov a rédigé la RFC: Fix foreach behavior, qui a été enrichie peu après, en vue d’uniformiser et de clarifier plusieurs cas un peu tordus (cette proposition apporterait aussi un gain potentiel de performances d’environ 1% sur certaines applications).

Stas Malyshev a annoncé l’ouverture des votes sur la RFC: Default constructors, qui proposait de systématiquement permettre d’appeler le constructeur d’une classe, y compris si elle n’en n’avait pas. Finalement, avec 27 votes pour et 20 votes contre, elle a été rejetée (une majorité de 2/3 était nécessaire pour qu’elle passe). Comme l’a fait remarquer Stas Malyshev, il est dommage que trop de personnes votant non n’expliquent souvent pas pourquoi. François Laupretre en a profité pour suggérer quelques idées qui pourraient peut-être améliorer les choses à ce niveau.

Suite à la discussion autour d’une PR répondant à une feature-request qui remontait à 2006, F & N Laupretre a rédigé la RFC: Add cyclic string replacements, qui propose d’ajouter un mode de remplacement cyclique aux fonctions str_[i]replace(). Une partie des retours ont été plutôt positifs, alors que d’autres ont indiqué que cette fonctionnalité ne leur semblait pas suffisamment importante pour avoir sa place dans la bibliothèque standard de PHP.

Andrea Faulds a noté que puisque PHP 7 semblait être l’occasion d’effectuer une petite passe de ménage, il pourrait être intéressant de faire quelque chose à propos des fonctions de génération de nombres aléatoires rand() et mt_rand() – la première étant lente et peu efficace, alors que c’est celle qu’un nouvel arrivant aura naturellement tendance à utiliser – et a suggéré un plan d’attaque. Les premiers retours ont été plutôt positifs, même si d’autres ont souligné qu’il était important de ne pas casser l’existant en supprimant des fonctions répandues.

F & N Laupretre a rédigé la RFC: Improve array to string conversion, qui propose soit de supprimer complètement la conversion tableau → chaine (qui donne aujourd’hui "Array" et génére une notice), soit de la gérer réellement. Il n’y a eu que peu de retour sur ce sujet, mais j’aimerais le voir progresser d’ici PHP 7, considérant que cette conversion n’est que rarement utile – et à chaque fois que j’ai rencontré cette notice, elle m’a permis d’identifier un bug !

Niklas Keller a suggéré qu’il pourrait être sympathique d’avoir un opérateur in, qui remplacerait à la fois in_array() et certains usages de strpos().

Bob Weinand a écrit la RFC: Remove the date.timezone warning qui propose de supprimer l’avertissement qui est actuellement généré lorsque l’on essaye d’utiliser une fonction de manipulation de date sans avoir configuré la timezone à utiliser (directive date.timezone). Supprimer cet avertissement serait appréciable, mais il est important de configurer correctement ce point, même si UTC semble souvent (mais pas toujours) être un choix raisonnable, et déterminer automatiquement la timezone du système n’est pas évident.

Michael Wallner a relancé la discussion autour de la RFC: Add pecl_http to core, qui propose d’inclure l’extension PECL pecl_http au cœur de PHP.

Suite à, entre autres, une remarque de Remi Collet en octobre à propos de problèmes de licence (qui sont suffisant pour justifier cette proposition) autour de l’extension ext/json de PHP, Jakub Zelenka a rédigé la RFC: Replacing current json extension with jsond, pour laquelle les votes ont été ouvert à la fin du mois.

Thomas Bley a annoncé la RFC: Allow error_handler callback parameters to be passed by reference, qui propose de permettre aux fonctions de gestion d’erreurs configurées via set_error_handler() de modifier leurs paramètres, qui seraient passés par référence, typiquement pour enrichir des messages d’erreurs. Xinchen Hui a souligné qu’utiliser un gestionnaire d’erreurs personnalisé était probablement plus adapté, dans ce type de cas – et Stas Malyshev a ajouté que modifier une donnée qui devrait être interne à PHP était étrange.

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.