Ce mois-ci sur internals@php - Octobre 2014

This post is also available in English.

809 messages ont échangés en octobre 2014 sur la mailing-list internals@ de PHP, soit un peu plus qu’en septembre.

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

Pour commencer, soulignons que PHP 5.6 est entrée dans son cycle de vie normal, avec la sortie de la première version de maintenance au début du mois.

Nikita Popov a rédigé la RFC: Remove deprecated functionality in PHP 7, qui propose de supprimer de PHP 7 tout ce qui a été marqué comme obsolète sur les différentes versions 5.x dont, notamment : ext/ereg, ext/mysql, l’affectation de new par référence, les fonctions de manipulation des magic_quotes, les commentaires # dans php.ini, … Du fait de l’impact que pourrait avoir la suppression des deux premiers points, il se pourrait que la RFC soit votée en trois fois (un vote pour chacun des deux premiers points et un troisième pour tout le reste).

Comme l’a souligné Kris Craig, ext/mysql, en particulier, est obsolète depuis un bon moment – et le fait que certains sites et tutoriaux continuent à y faire référence ne doit pas empêcher sa suppression. Toutefois, Rasmus Lerdorf a noté que la plupart des utilisateurs obtiennent leurs installations et extensions PHP depuis leurs distributions et que celles-ci ont tendance à packager des extensions PECL comme si elles étaient fournies directement avec PHP.

Johannes Schlüter a fait remarquer que, indépendamment de la suppression ou non de ext/mysql, il était important d’éduquer les utilisateurs pour qu’ils arrêtent d’utiliser cette extension – et Derick Rethans a ajouté que le fait que ext/mysql ait une interface procédurale n’était pas une raison suffisante pour justifier son retrait. Zeev Suraski a quant lui rappelé qu’à chaque fois qu’une fonctionnalité était cassée ou supprimée, il était un peu plus difficile pour les utilisateurs d’effectuer une mise à jour.

D’un autre côté, comme l’a indiqué Pierre Joye, si les fonctionnalités obsolètes ne sont jamais supprimées, il n’y a pas d’intérêt à les marquer comme obsolètes et on pourrait tout aussi bien cesser de le faire.

En milieu de mois, Zeev Suraski a annoncé la RFC: PHP 7.0 timeline, qui proposait de sortir PHP 7 assez rapidement (d’ici un an), quitte à se limiter un peu sur les fonctionnalités : les points cassant la compatibilité devraient nécessairement arriver pour PHP 7.0 (puisque les BC-breaks ne sont permis que pour des versions majeures), mais d’autres fonctionnalités, n’entraînant pas de BC-break, pourraient ne viser que PHP 7.1 ou 7.2. Attendre trop longtemps risquerait aussi de mener à une version apportant un grand nombre d’incompatibilités, qui nuiraient à son adoption.

Xinchen Hui a enchainé en indiquant qu’il trouvait que un an était un peu long. D’autres ont rapidement noté qu’il valait mieux ne pas aller trop vite : pas mal d’idées pourraient encore être prises en compte pour PHP 7 – même si seuls les points cassant la compatibilité doivent impérativement aller dans la version 7.0 (par contre, il ne faudrait pas en oublier, pour éviter de devoir à nouveau ré-attendre dix ans).

Comme l’a noté Rasmus Lerdorf, la branche master peut aussi demander un peu de temps avant d’être stabilisée – encore plus sur un projet avec pas mal de code legacy, comme PHP, où chaque changement peut avoir des conséquences qui ne sont pas toujours bien anticipées.

Avec l’ajout des fonctions variadiques en PHP 5.6, Marco Pivetta a proposé de marquer comme obsolètes pour PHP 5.7 les fonctions call_user_func, call_user_func_array, func_get_args, func_num_args et func_get_arg – en vue de les supprimer ensuite, pour PHP 7. Elles pourraient, au besoin, être ré-implementées en espace utilisateur, pour aide au niveau de la compatibilité des applications les utilisant.

Andrea Faulds a répondu que la possibilité de ré-implémenter ces fonctions en espace utilisateur ne signifiait pas une grosse cassure au niveau de la compatibilité des applications, qui ne fonctionneraient plus de base sous PHP 7. Supprimer ces fonctions n’apporterait d’ailleurs aucun réel gain.

D’un autre côté, l’idée de supprimer des fonctions (désormais inutiles) du cœur de PHP pour les déplacer vers l’espace utilisateur a aussi du sens… Même si ça ne serait pas nécessairement optimal niveau performances.

Après la mise en place pour phpdbg d’un nouveau protocole XML de debuggage distant, Pierre Joye a noté qu’il pourrait être intéressant de voir s’il était possible de se rapprocher du protocole DBGp déjà utilisé par Xdebug. Joe Watkins a expliqué que ce nouveau protocole avait été mis en place suite à des échanges avec les développeurs de PhpStorm. Bob Weinand a ensuite listé quelques différences entre ces deux protocoles – qui auraient peut-être pu être ajoutés à DBGp ?

Stas Malyshev a également souligné que travailler hors du projet PHP pendant plusieurs semaines avant de merger une fonctionnalité entière n’était peut-être pas la meilleure façon de procéder pour un composant intégré à PHP : plus d’échanges auraient pu avoir lieu si les développements avaient été effectués sur une branche du repository de PHP même (bon, ça n’a pas forcément été le cas par le passé – mais il en va de même pour tout PHP, dont les modifications ne sont que peu revues). Cela dit, il serait intéressant que le travail produit ici puisse servir de base au développement d’un protocole unifié de débuggage pour PHP.

David Soria Parra a ensuite fait remarquer qu’il aurait pu être profitable de passer par une RFC, pour réfléchir à l’éventuelle mise en place d’un nouveau protocole et à la solution la plus adaptée. Julien Pauli a ajouté qu’il était étrange d’avoir un site distinct pour phpdbg (ça n’est pas une habitude pour les composants de PHP) et que son contenu pourrait être déplacé vers php.net (il semblerait que ce soit prévu). phpdbg faisant partie de PHP, il devrait suivre les processus de PHP.

Quelques jours plus tard et suite à des suggestions dans le sujet de discussion précédent, Ferenc Kovacs a expliqué que les RM de PHP 5.6 avaient décidé d’annuler des modifications apportées récemment à phpdbg (support du debuggage à distance) et pas encore publiées : à partir du moment où ce composant fait partie de PHP, ses évolutions majeures peuvent demander une phase de stabilisation et elles devraient suivre le processus mis en place pour les évolutions de PHP – notamment, en passant par des RFCs. Les modifications en question ont été annulées quelques heures plus tard, en vue de revenir dans le futur de façon plus posée.

Andrea Faulds a rédigé la RFC: Big Integer Support, qui propose de mettre en place, en interne, deux types d’entiers : les entiers traditionnels (limités aux nombres pouvant tenir sur 32 ou 64 bits) et des entiers basés sur GMP, qui permettraient de manipuler des nombres aussi grands que souhaité. Ces deux types internes seraient perçus par l’utilisateur comme un unique type entier, sans limite de taille.

Stas Malyshev a fait remarquer qu’ajouter un nouveau type interne demanderait à ce qu’il soit pris en compte par toutes les extensions PHP, qui devraient donc, pour beaucoup, être adaptées.

La RFC a été mise à jour un peu plus tard pour tenir compte de problématiques de licence éventuellement posées par l’utilisation de GMP. Un benchmark a aussi été publié pour montrer que cette proposition n’avait a priori pas d’impact réel sur les performances de PHP, même si des tests plus approfondis devraient être menés.

Après environ deux semaines, les échanges sur ce sujet se sont arrêtés, sans qu’une décision ait été prise. À voir dans les prochains mois si cette RFC reviendra sur l’avant de la scène.

Joe Watkins a annoncé la RFC: UString, qui vise à mettre en place, dans PHP, une nouvelle classe UString, qui disposerait du gros de ce qui est nécessaire pour manipuler des chaînes Unicode. En somme, cette classe UString viendrait en quelque sorte prendre la place de l’extension mbstring existante, qui n’est pas parfaite, avec une implémentation basée sur ICU (déjà utilisée par Intl), plus rapide que celle de mbstring.

Les premiers retours ont été plutôt positifs. Pierre Joye a ajouté qu’il serait bon que cette extension soit systématiquement activée, de manière à faciliter son adoption.

Dmitry Stogov a noté que si cette proposition n’incluait pas l’utilisation d’objets UString au sein du moteur ou pour d’autres extensions, elle était incomplète et ne répondrait pas à tous les besoins (par exemple, des chaînes unicode ne pourraient pas être utilisées comme clefs de tableaux, puisqu’il s’agirait d’objets et pas réellement de chaînes de caractères – sauf si une autre idée évoquée il y a quelques temps était acceptée). Bien sûr, comme l’a souligné Johannes Schlüter, une meilleure approche serait un véritable Unicode, mais PHP 6 a montré que ce n’était pas si facile.

Dans le fil de discussion précédent, Stas Malyshev a annoncé qu’il avait commencé à travailler sur la RFC: Objects as hash keys, qui propose qu’une nouvelle méthode magique (__hash() ou __toKey() par exemple) permette à des objets d’être utilisés comme clefs de tableaux.

Joe Watkins a répondu en suggérant que __toScalar() pourrait être un nom adapté, plus proche de ce que ferait effectivement cette méthode, sans se limiter au contexte actuellement discuté – mais ce nom n’expliquerait pas l’utilité de cette méthode.

Alexander Lisachenko a suggéré qu’utiliser une interface pour cela pourrait également être une bonne idée, au lieu d’ajouter une nouvelle méthode magique – même si la méthode magique serait plus dans la façon de faire de PHP.

Etienne Kneuss a fait remarquer que cette proposition ne visait en fait pas à véritablement utiliser des objets comme clefs de tableaux (ce qui demanderait de ré-écrire toute la gestion de HashTables de PHP), mais uniquement à simplifier quelques écritures. Et donc, foreach, key() ou array_keys() ne retourneraient pas un objet, mais uniquement son hash, tel que calculé par cette nouvelle méthode.

Andrea Faulds a rédigé la RFC: Readonly Properties, qui part du constat qu’il est aujourd’hui difficile de rendre une propriété lisible depuis l’extérieur d’une classe, sans pour autant la rendre accessible en écriture en même temps : il faut mettre en place des getters/setters et/ou jouer avec __get/__set (dans les deux cas, ça demande d’écrire du code, c’est peu efficace, … ). Pour répondre à cette problématique, il est proposé d’ajouter un nouveau mot-clef readonly, qui pourrait être employé sur les propriétés de classes, pour indiquer qu’elles doivent être accessibles depuis l’extérieur de celles-ci.

Rowan Collins a noté que cela permettrait de rapprocher les objets en espace-utilisateur de ceux exportés par certaines extensions (qui peuvent avoir des propriétés en lecture-seule) – et il serait effectivement agréable de ne plus avoir à écrire de nombreuses lignes de codes pour obtenir cette fonctionnalité. D’autres sont allés jusqu’à suggérer une gestion d’accès plus fine, avec une syntaxe du style var $callback as rwxrw---x;.

D’un autre côté, comme l’a fait remarquer Jordi Boggiano, il pourrait être préférable de re-débattre de la RFC: Property Accessors Syntax, qui allait plus loin, tout en permettant ce qui est proposé ici – qui ne répond qu’à une partie des besoins. Nikita Popov a aussi noté que le mot-clef readonly n’était pas forcément clair et que là où des méthodes getters pouvaient faire partie d’une interface, ce ne serait pas possible pour des propriétés. Peut-être qu’une possibilité serait de réserver dès maintenant la syntaxe permettant de mettre en place des accesseurs, tout en n’en implémentant qu’une partie pour l’instant ?

Finalement, Andrea Faulds a retiré cette RFC, qui était un peu confusante et ne répondait qu’à une partie des besoins.

Kris Craig a demandé pourquoi PHP disposait des variables super-globales $_GET et $_POST mais pas de $_PUT ni $_DELETE, qui pourraient être utiles dans le cas de développement d’APIs REST.

Comme l’a rapidement signalé Andrea Faulds, ces deux premières variables sont déjà mal nommées : $_GET correspond aux paramètres reçus par le biais de la query-string et $_POST contient les données du corps de la requête – ou alors, il faut considérer qu’elles correspondent aux méthodes de formulaires et non aux primitives HTTP. En pratique, passer à des variables comme $_QUERY, $_BODY et $_REQUEST pourrait avoir du sens, mais briserait complétement la compatibilité. D’un autre côté, Rasmus Lerdorf a fait remarquer que les utilisateurs savaient comment utiliser $_GET et $_POST et que vouloir ajouter des alias était peut-être aller un peu loin : de tout ce qui peut être source de confusion en PHP, ce point serait vers le bas de la liste.

Michael Wallner a alors souligné qu’il pouvait être intéressant de jeter à un coup d’œil à l’extension pecl_http ainsi qu’à la RFC: Add pecl_http to core.

La discussion a été intense, avec pas loin d’une centaine de mails en quelques jours, mais je n’ai pas le sentiment qu’elle ait mené à une décision. En tout cas, $_GET et $_POST ne sont pas prêt de disparaître – mais nous verrons peut-être apparaître de nouveaux alias dans le futur…

Quelques jours plus tard, Sherif Ramadan a annoncé avoir commencé à travailler sur la RFC: Standardized PHP Http Interface.

Florian Margaine a commencé par répondre que PHP devrait plus fournir des implémentations que des interfaces : libre à l’espace utilisateur de déterminer à quoi le code devrait ressembler. Supprimer les super-globales ($_GET, $_POST, …) casserait aussi quasiment toutes les applications existantes et nuirait fortement à l’adoption de PHP 7 – même si elles ne sont pas l’interface la plus parfaite qui soit.

D’un autre côté, les variables GPC ne sont pas réellement parfaites et une interface intégrée à PHP pourrait unifier un peu la façon dont chaque framework fournit une classe HttpRequest différente de celle des autres frameworks.

Larry Garfield a en parallèle rappelé qu’il y avait pas mal de discussions autour de ce sujet sur la mailing-list du FIG et que l’espace utilisateur était probablement plus adapté à ce type d’expérimentations.

Andrea Faulds a annoncé la RFC: Safe Casting Functions, qui partait du constat que les opérateurs de transtypage existant, explicites, n’échouent jamais et ne lèvent jamais d’erreur – ce qui peut être dangereux (surtout s’ils sont utilisés sur des saisies utilisateurs), puisqu’ils retourneront un peu n’importe quoi si les données sur lesquelles on les utilise correspondent elles-mêmes à un peu n’importe quoi.

Cette RFC proposait donc d’ajouter trois fonctions, qui valideraient leur entrée, au lieu de transtyper aveuglément :

• to_int() : n’accepterait que des entiers, des flottants contenant des entiers et pouvant être représentés par des entiers, ou des chaînes contenant la représentation textuelle d’entiers.
• to_float() : n’accepterait que des flottants, des entiers et des chaînes représentant des flottants.
• et to_string() : n’accepterait que des chaînes, des entiers, des flottants et des objets transtypables en chaînes.

La question de la valeur de retour de ces fonctions s’est rapidement posée (typiquement, est-ce que false est une valeur ?), de même que l’idée de leur faire lever des exceptions – ce qui pourrait dépendre d’un paramètre optionnel.

Stas Malyshev a souligné que des règles de validation existaient déjà dans l’extension ext/filter et qu’il faudrait peut-être enrichir celle-ci plutôt que d’ajouter un autre jeu de règles ailleurs. Utiliser des noms comme to_int() pourrait être source de confusion pour les utilisateurs, puisque le comportement ne serait pas le même que celui de (int) et un nom comme lossless_int() pourrait être plus adapté.

Les discussions n’étaient pas terminés en fin de mois et j’imagine que le sujet continuera sur le mois prochain ;-)

Nikita Popov a relancé la RFC: Exceptions in the engine, qui avait initialement été proposée pour PHP 5.6 – toutes les erreurs ne seront pas transformées en exceptions, mais une majorité le pourrait. Comme précédemment, les retours ont été plutôt positifis.

Thomas Gossmann a demandé s’il était possible de supprimer le mot-clef function des déclarations de méthodes. Levi Morrison a rapidement indiqué que cette idée avait été rejetée par le passé, typiquement parce qu’elle rendrait plus difficile la lecture du code et la recherche de définitions – sans pour autant apporter grand chose au langage. Il n’est d’ailleurs pas le seul de cet avis.

Les votes ont été ouvert sur la RFC: loop + or control structure. Avec 4 votes “pour” et 11 votes “contre”, elle n’est pas passée – Leigh, auteur de cette RFC, a expliqué pourquoi lui-même avait fini par voter contre. À voir si le sujet mérite que quelqu’un prenne la suite dans quelques temps.

Leigh a annoncé que la RFC: 64 bit format codes for pack() and unpack() était passée, avec 100% de votes “pour”.

Les modifications liées à la RFC: Catchable “call to a member function of a non-object”, qui était passée cet été, ont été mergées.

Davey Shafik a fait remarquer qu’une E_DERECATED était systématiquement levée, avec PHP 5.6, si always_populate_raw_post_data était configuré à une autre valeur que -1 – et la valeur par défaut est 0. Il s’agit cependant du meilleur compromis possible, avec une valeur de configuration par défaut qui ne casse pas la compatibilité, tout en avertissant les utilisateurs qu’elle correspond à une fonctionnalité qui sera supprimée dans le futur.

Suite à une question de Sebastian Bergmann, Adam Harvey a mis en place la nouvelle page Supported Versions sur php.net, qui indique quelles sont les versions actuellement supportées de PHP – et jusqu’à quand.

Stas Malyshev a remis en avant la RFC: Filtered unserialize() qui proposait de modifier la fonction unserialize() de PHP pour permettre d’interdire la dé-sérialisation d’objets ou de limiter celle-ci à un ensemble de classes listées.

Miloslav Hůla a rédigé la RFC: Access to aliases definition by reflection, qui propose d’exposer à l’espace utilisateur les définitions d’alias d’espaces de noms (obtenus avec use), par le biais de l’API de Reflection.

En milieu de mois, Levi Morrison a annoncé qu’il disposait d’une implémentation fonctionnelle pour la RFC: Return Type Declarations et que quelques petites modifications y avaient été apportées. Il est donc probable que les votes soient bientôt ouverts sur cette RFC.

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.