Ce mois-ci sur internals@php - Août 2013

Après juillet qui a marqué un premier mois de vacances d’été très calme avec 330 mails, voici mon dépilage d’internals@ pour le mois d’août 2013, qui a vu quelques discussions plus animées, et remonte à 451 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) :

Pour commencer : ça y est, PHP 5.5 semble vraiment avoir atteint son rythme de croisière, avec deux versions publiées ce mois-ci : PHP 5.5.2 et 5.5.3 – la norme étant aux environs d’une version par mois, sauf correctif de sécurité, ce qui a été le cas ici.

PHP 5.5 sortie et stabilisée, les discussions sur internals@ semblent repartir, avec plusieurs propositions – visant principalement ce qui est susceptible de devenir PHP 5.6, peut-être l’année prochaine.

Sean Cannella a rédigé la RFC: Constructor Argument Promotion, dont l’idée permettrait de raccourcir les constructeurs assignant leurs paramètres à des propriétés de l’objet en cours de construction.

Comme l’a fait remarquer Stas Malyshev, cette syntaxe ajouterait de la magie, susceptible de compliquer le debugging. Il n’était d’ailleurs pas le seul à estimer que supprimer quelques lignes de code PHP simple soit risqué, par rapport à la complexité apportée par la syntaxe. Cela dit, comme l’a indiqué Jordi Boggiano, si cela peut éviter plus que ces quelques lignes, ce serait autant de temps de gagné.

Suite à ces échanges, Matthieu Napoli a suggéré une autre syntaxe, qui serait plus intuitive, et a semblé rencontrer plus de succès.

La discussion n’a pas duré bien longtemps, et s’est rapidement essouflée ; nous verrons dans les prochains mois si le sujet revient sur le devant de la scène.

Yasuo Ohgaki a proposé de mettre en place un nouveau gestionnaire de sérialisation pour les sessions, qui ne souffrirait pas des limitations du composant utilisé actuellement (limitations historiquement dûe à register_globals, qui n’est désormais plus supporté) – en particulier, aujourd’hui, il n’est pas possible d’avoir une clef numérique comme entrée de session (par exemple, $_SESSION[123]).

Stas Malyshev a répondu qu’il ne voyait pas l’intérêt de casser la compatibilité au niveau de la gestion des sessions pour une limitation que peu d’utilisateurs rencontraient. Comme l’a alors fait remarquer Leigh, implémenter un nouveau gestionnaire est acceptable, mais il ne devrait probablement pas être activé par défaut, pour ne pas casser la compatibilité ascendante.

Finalement, une option php_serializer pourrait être ajoutée pour les sessions ; non-activée par défaut pour l’instant.

Anthony Ferrara a rédigé la RFC: Constant Scalar Expressions, qui permettrait à PHP d’accepter des expressions constantes, calculées à la compilation, là où seules des constantes sont aujourd’hui valides.

Comme noté par Pierre Joye, une expression est souvent plus facile à lire que son résultat (si on parle de secondes, 60*5 peut avoir plus de sens que 300 ; dans un contexte de flags par bits, 1<<7 peut aussi être plus compréhensible que 127).

Stas Malyshev a fait remarquer qu’il était dommage que cette proposition ne supporte pas l’utilisation de constantes dans l’expression. Mais mettre en place la gestion de constantes semble être plus difficile ; et serait donc à traiter dans un second temps.

La RFC n’est pas encore arrivée à l’étape de votes, mais les retours ont l’air plutôt positifs (du moins tant qu’on ne parle pas d’utiliser des constantes dans l’expression – et la RFC n’en parle pas). A voir comment les choses évolueront, mais ça me semble plutôt bien parti !

Terry Ellison a demandé quels systèmes d’exploitations et quelles SAPI PHP 5.6 devrait supporter – l’idée étant que moins d’OS/SAPI à supporter signifie moins de temps à passer en tests/maintenance/corrections sur des plate-formes peu utilisées (la discussion tournait autour d’éventuelles améliorations pour ext/opcache, mais la question est plus générale).

Comme l’a fait remarquer Johannes Schlüter¹, sortir des extensions vers PECL est relativement facile ; mais ce type d’approche est plus difficile pour les SAPI, qui ne peuvent pas réellement vivre hors de l’arborescence de PHP.

Les discussions ont continuées autour de la RFC: Importing namespaced functions, qui avait été rédigée le mois dernier.

Dans l’ensemble, les retours ont été plutôt positifs ; notamment parce que cette idée permettrait de remplacer des fonctions internes, et parce qu’elle montre une volonté de continuer à améliorer les choses pour PHP côté non orienté objet. Quelques retours ont aussi été fait en vue de corriger certains bugs de l’implémentation proposée.

Suite aux discussions, cette RFC: Importing namespaced functions a été ouverte aux votes. Avec 16 votes “pour” et 4 votes “contre”, elle est passée !

Il y a quelques semaines, on a beaucoup entendu dire que “le support de JSON serait supprimé de PHP”, en raison d’un problème de licence. Bien sûr, les choses sont loin d’être aussi graves – et en fait, le sujet n’a que peu été abordé sur internals@ : le composant JSON “de base” n’est pas libre au sens qui va bien du terme ; un autre composant existe depuis quelques temps, actuellement dans PECL ; une discussion est en cours pour voir ce qui pourrait être fait pour remplacer le composant “de base” par ce composant “PECL” – cela passera probablement par une RFC, une analyse des éventuelles différences de comportements et éventuelles différences au niveau des performances. Ce composant pourrait peut-être être intégré pour PHP 5.6.

Effectivement, peu de temps après, Remi Collet a annoncé la RFC: Switch from json extension to jsonc.

Cette nouvelle implémentation semble plus lente pour le décodage de JSON que l’implémentation actuelle non-libre, et comme l’a souligné Zeev Suraski, une partie importante des utilisateurs de PHP risque d’avoir du mal à comprendre qu’une nouvelle implémentation plus lente ait été retenue, uniquement à cause d’un détail de licence – et ce d’autant plus que changer d’implémentation risque toujours d’introduire de nouveaux bugs.

Nikita Popov a rédigé la RFC: Syntax for variadic functions, qui permettrait à une fonction d’accepter un nombre variable de paramètres, sans avoir à passer par func_get_args().

Comme l’a souligné Lazare Inepologlou, cela rend le code plus explicite : en regardant la définition de la fonction, son prototype, on comprendre immédiatement qu’elle accepte un nombre variable d’arguments.

Cette proposition étant arrivée en toute fin de mois, elle n’a pas encore été débattue très activement ; mais les premiers retours ont l’air plutôt positifs. Je suis curieux de voir si les discussions se poursuivront le mois prochain, et comment cette RFC évoluera !

En complément, Nikita Popov a aussi proposé la RFC: Argument Unpacking.

Les retours sont allés un peu dans les deux sens, entre ceux qui trouvent la syntaxe peu lisible au premier abord, ceux qui accepteraient que cette nouvelle idée ne s’applique qu’au dernier paramètre d’une fonction (notamment du fait que les arguments sont passés/reçus, en PHP, par position), et ceux qui apprécieraient de pouvoir se passer de pas mal d’usages de call_user_func().

Après… Comme l’a laissé entendre Pierre Joye, il va peut-être être temps de reparler de paramètres nommés…

J’ai l’impression que le sujet n’est pas tout à fait nouveau ; mais, cette fois, les choses sont faites de manière un peu plus formelle : Anthony Ferrara a publié une version brouillon de la RFC: Function Autoloading, dont l’idée est de permettre l’autoloading de fonctions et constantes – et plus uniquement de classes/interfaces/traits.

Comme l’a rapidement fait remarquer Stas Malyshev, là où les classes vont bien avec le principe d’un autoloader (généralement un fichier par classe), c’est souvent moins vrai pour les fonctions. Cela dit, une approche avec un fichier de fonctions par espace de noms serait probablement tout à fait acceptable.

Toutefois, un mécanisme d’autoloading pour les fonctions éviterait le reccours à des astuces du genre “passer par des méthodes statiques pour bénéficier de l’autoloading via la classe” (Genre l’adorable classe Utils – ou équivalent – qu’on trouve dans pas mal de projets…). Cela permettrait aussi à l’approche fonctions de bénéficier d’un outil extrêmement pratique, aujourd’hui réservé à la seule approche classes.

Bien sûr, la discussion est passée par l’argument “il n’y a pas ça dans symfony ou Zend Framework” – mais en même temps, si la fonctionnalité n’existe pas, elle ne risque pas d’être utilisée ; et les frameworks les plus populaires ne représentent probablement pas non plus l’ensemble des développeurs utilisateurs de PHP.

Cette discussion n’ayant commencée qu’en toute fin de mois, elle n’est pas encore arrivée à sa conclusion ; la RFC elle-même n’est encore qu’en statut brouillon. Je suis curieux de voir comment elle évoluera sur les prochaines semaines, considérant que les avis divergent fortement quant à l’utilité d’une telle fonctionnalité.

Lior Kaplan a continué à envoyer toutes les semaines un rapport sur les pull-requests en cours / mergées / fermées sur github. Voir aussi ce mail et celui-là : les PR sont traitées de plus en plus rapidement, ce qui est plutôt bon signe !

Yasuo Ohgaki a créé la FR: #65501 uniqid(): More entropy parameter should be true by default. En complément, Nikita Popov a ajouté que uniqid() est nettement plus rapide si on lui passe true en second paramètre. Toutefois, cette modification impactant la longueur de la donnée retournée par la fonction, elle ne devrait pas être effectuée à la légère.

Michael Wallner a mergé un correctif qui permet d’uploader des fichiers de taille supérieure à 2GB.

Yasuo Ohgaki a travaillé sur la FR #17860: auto detect whether session changed : plutôt que d’écrire les données de session à la fin de chaque requête, une optimisation serait de ne les écrire que si elles ont été modifiées (et, dans le cas contraitre, de changer la date de dernière modification du fichier, en cas de données enregistrées en fichiers, pour ne pas casser le garbage collector de sessions – ce qui serait tout de même plus rapide que de ré-écrire l’ensemble des données pour rien). Voici un petit gain de performances pour (probablement) PHP 5.6 !

En parlant d’optimisations, Nikita Popov a appliqué un patch permettant d’éviter une copie de données pour les fonctions retournant un tableau autrement que par référence.

La fonction crypt() appelée avec un seul paramètre génére un hash très faible. Une RFC a été créée pour déterminer quelle serait la meilleure solution à mettre en place pour prévenir les utilisateurs et éviter ce type de cas.

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.

Note à moi-même : [le commentaire](http://news.php.net/php.internals/68570) sur les mauvaises performances avec TSRM est assez joli *(un cache d'opcodes ne servirait pas à grand chose dans un environnement threadé, tellement les perfs sont déjà mauvaises)*. Voir aussi [cette réponse](http://news.php.net/php.internals/68582) qui parle de 20% de pertes de perfs.