Ce mois-ci sur internals@php - Septembre 2013

Après août, second mois des vacances d’été, raisonablement calme avec 451 mails, voici mon dépilage d’internals@ pour le mois de septembre 2013, qui a vu plusieurs discussions animées, et a re-passé pour la première fois en six mois la barre des 500 mails, arrivant à un total de 625 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) :

Johannes Schlüter a rédigé un mail où il a listé les différentes évolutions et versions que PHP a connu depuis PHP 5.2 en 2006 : cela commence à en faire une bonne petite liste, qui font de PHP un langage qui évolue vite depuis quelques années – surtout si on compare son évolution à celles de C, C++, ou JAVA.

Ces évolutions sont une très bonne chose pour la plupart d’entre nous, mais deux problèmes se posent, en termes de maintenance :

• D’une part, les nouvelles versions de PHP ne sont adoptées que lentement,
• Et là où pas mal d’attention est concentrée sur les évolutions, en face, les bugs s’empilent (aujourd’hui, il y a environ 4000 tickets ouverts).

En conséquence, il serait probablement profitable de ralentir un peu le rythme des évolutions pendant quelques mois, pour consacrer un peu plus d’énergie à la maintenance de l’existant – maintenance nécessaire pour assurer la viabilité de notre langage de prédilection !

Stas Malyshev a annoncé avoir mis à jour la RFC: Skipping optional parameters for functions, qui permettrait d’invoquer une fonction sans avoir à spécifier de valeur pour ses paramètres optionnels non situés en fin de liste d’arguments :

// Déclaration de fonction 
function create_query($where, $order_by, $join_type='INNER', 
    $execute = false, $report_errors = true) {
    // ...
}

// Appel sans passer les 3ème et 4ème paramètres,
// qui prendraient leur valeur par défaut, spécifiée
// lors de la déclaration de la fonction
create_query("deleted=0", "name", default, default, /*report_errors*/ true);

Une proposition serait de ne pas du tout spécifier de valeur, plutôt que de réutiliser le mot-clef default, mais cela pourrait nuire à la lisibilité.

Bien sûr, comme l’a fait remarquer Florin Patan (qui n’est pas le seul de cet avis), implémenter une fonctionnalité de paramètres nommés résoudrait aussi ce problème ;-)

Au bout de quelques jours, la discussion s’est essouflée, et n’a pas avancée depuis plus de trois semaines.

Dans la foulée, Nikita Popov a annoncé avoir commencé à travailler sur la RFC: Named Parameters.

Cette idée de paramètres nommés est assez fréquemment évoquée depuis pas mal de temps (c’est une syntaxe qui existe notamment en Python, si j’ai bonne mémoire), et les premiers retours ont clairement indiqués que l’idée semblait intéressante pour beaucoup d’entre nous.

Au niveau des réserves, certains ont noté que cela signifie que les noms de paramètres ne devraient plus être modifiés une fois une bibliothèque publiée, et qu’il ne faudrait pas que cela encourage les développeurs à mettre en place des fonctions prenant trop d’arguments.

Bien sûr, il faudrait s’assurer que cette nouvelle possibilité syntaxique n’a pas d’impact négatif au niveau des performances (à première vue, ça semble correct),

Les discussions ne sont pas terminées, la syntaxe elle-même n’étant pas encore définie, de même que les erreurs pouvant être levées ou même le périmètre fonctionnel précis souhaité – plusieurs éléments de réponse ont été apportés par Nikita Popov dans ce mail. En tout cas, je suis curieux de voir l’évolution de cette propositions sur les prochains semaines !

Joe Watkins a annoncé avoir rédigé la RFC: Anonymous Classes, qui introduit le même type de fonctionnalité que les fonctions anonymes arrivées en PHP 5.3, mais pour des classes.

En copiant-collant un exemple d’idée postée par Michael Wallner, la syntaxe pourrait ressembler à quelque chose de ce type :

$subject->attach(new class implements SplObserver {
    function update(SplSubject $s) {
        printf("Got update from: %s\n" $subject);
    }
);

Bien sûr, cette proposition a levé la question de l’utilité d’une telle possibilité, et des cas d’utilisation correspondant (cette possibilitée est fréquemment utilisée en JAVA, par exemple, où des objet anonymes implémentant une interface peuvent être utilisés comme callbacks). S’est aussi posée la question de la sérialisation/désérialisation d’un objet instance d’une classe non-nommée.

La RFC a été enrichie suite aux discussions, et des ajouts complémentaires comme l’imbrication de classes sont déjà évoqués (mais probablement sous forme d’autres RFC). Je suis curieux de voir l’évolution de ce sujet sur les prochains mois.

D’ailleurs, alors que le mois touchait à sa fin, Joe Watkins a annoncé avoir rédigé un premier brouillon pour la RFC: Nested Classes. Faute de temps, celle-ci n’a pas encore été réellement discutée ; mais là encore, nous verrons dans les prochaines semaines les réactions que le sujet ne va pas manquer de lever !

La RFC: Syntax for variadic functions dont je parlais le mois dernier a été soumise aux votes. Avec 36 votes pour et 1 vote contre, elle est passée !

PHP 5.6 devrait donc supporter la syntaxe suivante (exemple repris de la RFC) :

class MySQL implements DB {
    public function query($query, ...$params) {
        $stmt = $this->pdo->prepare($query);
        $stmt->execute($params);
        return $stmt;
    }
    // ...
}

Ici, la syntaxe ...$params indique que query() est une fonction variadique, et que tous les arguments suivant $query doivent être placés dans le tableau $params.

Bob Weinand a annoncé avoir développé un patch qui permettrait d’utiliser des mot-clefs comme identifiants¹ (noms de fonctions / classes, étiquettes, …) ; cela réduirait l’impact de la liste de mot-clefs réservés.

Il semblerait que l'idée avait déjà [été évoquée](http://news.php.net/php.internals/23254) par Ralph Schindler en 2006.

Les retours ont été plutôt positifs dans l’ensemble, nombreux développeurs souhaitant parfois utiliser une partie de ces mots-clefs (comme list, par exemple) ; et les tests effectués n’ont pas mis en évidence d’impact significatif sur les performances. Cela dit, comme l’a souligné Johannes Schlüter, PHP se retrouverait alors avec deux listes de mots-clefs, certains pouvant être utilisés à certains endroits et pas d’autres – ce qui risque de complexifier les choses pour les utilisateurs, par rapport à une unique liste de mots-clefs ne pouvant être employés nulle part.

La modification n’étant pas réellement mineure, et la discussion identifiant plusieurs points sur lesquels plus de réflexion semblait nécessaire, Pierre Joye a finalement proposé qu’une RFC soit rédigée à ce sujet – et donc, Bob Weinand a rédigé la RFC: Extended keyword support.

Gordon Oheim a rédigé la RFC: Automatic Property Initialization, où il proposait qu’une écriture du type suivante :

class Point 
{
    private $x, $y;
    
    public function __construct($x, $y)
    {
        $this->x = $x;
        $this->y = $y;
    }
}

Puisse être remplacée par une syntaxe alternative, plus courte :

class Point
{
    private $x, $y;

    public function __construct($this->x, $this->y);
}  

Il n’y a pour l’instant eu que peu de retours sur cette proposition, qui a semblé être appréciée, même si la syntaxe peut sembler surprenante – et qu’une autre solution serait d’implémenter la fonctionnalité d’accesseurs qui avait été discutée il y a quelques mois.

Plus ou moins suite au départ d’Anthony Ferrara au tout début du mois, Florin Patan a posté un mail intitulé “Wake up”, où il soulignait le fait que le développement de PHP n’est pas aussi ouvert d’esprit qu’il le pourrait.

Une des premières suggestions qui est remontée évoquait l’idée de passer de la mailing-list internals@ à un forum, qui, possiblement, faciliterait les échanges. Sans surprise, cette idée n’a initialement pas été fort bien accueillie par tout le monde (avec un logiciel de messagerie correct, une mailing-list est utilisable ; à condition que ses membres suivent l’étiquette qui va bien). D’un autre côté, un forum pourrait permettre, par un système de votes, de mettre en évidence les discussions intéressantes, tout en poussant vers le bas les échanges moins constructifs et en permettant d’ignorer plus facilement les posts hors-sujet.

Cela dit, Terence Copestake a peut-être cerné une partie du problème, lorsqu’il a souligné qu’il y avait un conflit entre ceux qui voulaient que PHP reste un langage simple et accessible, et ceux qui voulaient en faire un outil/environnement professionnel complet – les deux visions s’opposant, sans personne pour réellement trancher.

Peut-être faudrait-il aussi que, comme le disait Jordi Boggiano, chacun respire un grand coup avant de répondre à un point qui les a énervé…

En rebondissant sur ce qui s’était dit sur le sujet précédent, Andrea Faulds a lancé un autre sujet de discussion, à propos de cette idée de forum ; une solution mélant hiérarchie et système de votes pourrait d’après lui compléter internals@. Pour éviter de couper les conversations entre ceux utilisant un système et ceux restant sur l’autre, il faudrait une synchronisation entre les deux mécanismes, ou même que la solution de forum agisse comme une surcouche à internals@.

C’était en toute fin de mois dernier, donc je n’en n’ai pas parlé à ce moment là : Johannes Schlüter a fait remarquer que, en l’état, windows.php.net n’était pas des plus utiles (pas à jour, downloads ne passant pas par les mirroirs, …). Après avoir répondu à pas mal des questions posées, Pierre Joye a aussi annoncé que du travail était en cours sur la construction automatique pour Windows des extensions PECL. Un peu dans la même veine, PHP 5.2, qui a atteint son EOL il y a plusieurs années, a été retirée de la page de téléchargements de windows.php.net.

Nikita Popov a annoncé avoir terminé la rédaction de la RFC: Argument Unpacking, reprenant une idée qui existe, par exemple, en Python, Ruby, ou Javascript – et faisant assez logiquement le lien avec la RFC: Syntax for variadic functions, passée un peu plus tôt. Cette RFC est arrivée en fin de mois, et n’a vu que peu de discussions (ce qui est souvent bon signe) ; à suivre dans les prochaines semaines, donc.

Comme sur les mois précédents, Lior Kaplan a continué à poster régulièrement des mails résumant l’activité autour des Pull Requests faites sur PHP.

Suite aux discussions du mois dernier à propos de l’implémentation d’un nouveau serializer, Jakub Zelenka a mis à jour la RFC: Internal Serialize API.

La RFC: Change crypt() behavior w/o salt a été ouverte aux votes. La période de votes n’est pas terminée, mais il semblerait que les choses s’orientent vers la levée d’une notice dans le cas d’un appel à crypt() en omettant le paramètre $salt.

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.