Ce mois-ci sur internals@php - Juillet 2013

Après une succession de mois, comme mai et juin, très calmes, voici mon dépilage d’internals@ pour le mois de juillet 2013, qui a été encore plus loin niveau calme, avec seulement 330 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) :

C’était prévu depuis quelques temps : suite à la sortie de PHP 5.5.0, Johannes Schlüter a annoncé que PHP 5.3 a atteint sa Fin de Vie, et que PHP 5.3 ne recevrait plus que des correctifs de sécurité – et ce pour une durée de un an.

Il est donc plus que temps de passer à PHP 5.4, qui est stable depuis plus d’un an ; ou même, de monter directement à PHP 5.5, qui a été déclarée stable il y a un peu plus d’un mois.

En parallèle, PHP 5.5 semble commencer à suivre un cycle d’une version mineure par mois (comme le fait PHP 5.4 depuis un bon moment, et comme l’a aussi fait PHP 5.3) : PHP 5.5.1 a été publiée le 18 juillet.

Chris London a évoqué l’idée d’ajouter à l’instruction foreach() une syntaxe du type foreach ($array as $key => ) {}, qui pourrait servir lorsque l’on souhaite itérer seulement sur les clefs d’un tableau.

Ajouter un nouveau cas pour cette situation ne semblait pas nécessaire à Robin Speekenbrink, qui a proposé d’utiliser array_keys(). Mais comme l’a ensuite souligné Nikita Popov, c’est un cas où la fonctionnalité de Générateurs introduite en PHP 5.5 serait utile, évitant de charger en mémoire l’ensemble des clefs du tableau.

Lior Kaplan a fait une première passe sur les Pull Requests Github en attente, en vue de faire un peu de tri entre celles qui peuvent être mergées, celles qui ont des impacts importants et pourraient nécessiter une RFC, et celles pour lesquelles une intervention de l’auteur d’origine est souhaitée.

Différents types de problèmes semblent se poser, lorsqu’il s’agit de ces PR non-mergées :

• Dans certains cas, ceux qui les ont soumises disparaissent,
• Il arrive que des PR soient soumises sans test associé – et les développeurs existant n’auront pas forcément le temps d’écrire des tests pour une fonctionnalité qu’ils n’ont pas eux-même poussée (comme l’a noté Stas Malyshev, il est plus intéressant de passer du temps à merger des PR complètes que de travailler sur d’autres incomplètes),
• Occasionnellement, les discussions sur une PR en viennent à stagner,
• Et, malheureusement, il n’y a pas assez de développeurs de PHP suivant les PR – et étant à même de comprendre les patchs soumis en vue de les valider.

Lior Kaplan a depuis continué à rédiger ce type de rapports ; j’espère que cela permettra aux PR d’être plus rapidement prises en compte.

Chris London a fait remarquer qu’il était possible d’incrémenter des lettres, mais pas de les décrémenter ; il a donc proposé d’implémenter cette fonctionnalité – ou de lever un avertissement indiquant que ceci n’est pas possible. Effectivement, comme l’a noté Martin Amps, il pourrait être bon de clarifier comment fonctionnent les manipulations de chaînes avec les opérateurs arithmétiques.

Yasuo Ohgaki a indiqué que ces comportements sont documentés, et implémentés de la sorte depuis des années.

Cela dit, j’aurais assez tendance à être d’accord avec Dan Cryer qui demandait quelle utilité il pouvait y avoir à utiliser des opérateurs mathématiques avec des chaînes de caractères.

Les language constructs comme isset() ou echo ne sont pas callable. Daniel Lowrey a demandé à quel point ceci est profondément ancré dans le moteur de PHP, et s’il y avait des chances pour que cela change un jour.

A cette question, Johannes Schlüter a répondu que les constructions langage n’avaient pas nécessairement la même sémantique que les fonctions. Par exemple, pour isset(), le paramètre n’est pas passé par la pile de paramètres standard, mais directement comme opérande de l’opcode correspondant – c’est d’ailleurs un élément fondamental qui permet de ne pas lever de notice lorsque isset() est invoqué sur une variable inexistante.

Pour echo et print, le fait que ces constructions soient utilisables sans parenthèses (et soient utilisées ainsi absolument partout) fait à lui seul qu’il ne serait pas envisageable d’en faire des fonctions.

Yasuo Ohgaki a demandé en quoi une portion de code comme echo ++$a + $a++; pouvait mener à un résultat non-défini ; et a rapidement modifié la documentation pour supprimer l’avertissement correspondant.

Sara Golemon a par la suite rédigé une réponse expliquant plus précisément ce qui était indéfini et pourquoi ; d’après elle, et d’après d’autres, la modification de documentation devrait être annulée.

Finalement, Yasuo Ohgaki a annulé son commit sur la documentation, et même proposé d’améliorer celle-ci.

Je parlais le mois dernier de l’idée qu’avait évoquée Florin Patan d’ajouter à PHP la notion de retour typé. Sara Golemon a fait remarquer que ceci existait déjà dans HHVM, et que si c’était aussi implémenté dans PHP, il serait intéressant que les deux implémentations suivent la même logique, plutôt que de partir chacune dans leur direction.

Igor Wiedler a remis en avant le sujet de l’import de fonctions namespacées, pour lequel il avait rédigé la RFC: Importing namespaced functions il y a quelques mois de cela. Suite aux premiers retours, la RFC a été mise à jour pour ajouter le support de constantes namespacées.

En toute fin de mois, Julien Pauli a proposé d’ajouter une méthode \closure::isbindable(), permetant de déterminer si une closure données est ou non bindable.

Notons aussi que plusieurs sujets de discussion ont évoqué des travaux en cours, corrections de bugs et améliorations mineures – par exemple, sur PDO_DBLIB et les extensions PostgreSQL, ou sur l’extension AOP.

Nous voila sur les deux mois de congés d’été, et cela se sent sur internals@ : peu de discussions sont actives, et elles voient moins d’intervenants et d’échanges que ce que l’on peut usuellement constater le reste de l’année… Néanmoins, les idées continuent d’arriver, et les discussions ne s’arrêtent pas ;-)

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.