Toutes les fin de mois¹, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou, qui s’en occupe depuis quelques mois :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.

L’apéro du 25 septembre 2013 était un peu particulier, puisqu’il a réuni des développeurs PHP et des développeurs Python, un développeur de chacune des deux communautés présentant son langage aux développeurs de l’autre communauté.

Les slides que j’ai utilisés comme support pour présenter PHP aux développeurs Python sont disponibles en ligne² : Présentation de PHP, pour des développeurs Python.

Les slides utilisés par Arthur Vuillard, qui a fait la présentation inverse, sont eux aussi disponibles : Python pour les dévs PHP.

Au cours de cet article, je vais expliquer comment installer OpenGrok, un logiciel permettant de naviguer dans du code source, et d’effectuer des recherches dessus, depuis une interface web.

Mais pourquoi un indexeur de code-source ?

Il m’arrive fréquemment d’avoir besoin de naviguer dans du code source qui n’est pas actuellement ouvert dans mon IDE ; en particulier, je pense aux situations suivantes :

• Je ne suis pas à mon poste, et je n’ai pas accès à un IDE, ou même au code-source :
  • Par exemple, je veux montrer une portion de code à un collègue (qui peut travailler sur un autre projet que moi, et ne pas avoir sur son poste le code-source de mon projet),
  • Ou je suis en intervention depuis un autre PC que le mien, sans accès au code-source de l’application que je dépanne (autre qu’un vim dans un terminal), et ai besoin de chercher la cause d’une erreur (et sur des centaines de milliers de lignes, grep est parfois quelque peu insuffisant),
• Ou je suis en pleine revue de code sur un diff correspondant à une application autre que celle sur laquelle mon IDE est ouvert, et souhaite voir comment est implémentée une classe que je vois être utilisée,
• Ou encore, je souhaite accéder à une portion de code sur une autre branche de l’application sur laquelle je travaille, mais sans vouloir prendre le temps de checkouter cette branche,
• Voire même, je veux rechercher tous les usages d’une fonction dans le code-source d’un projet que je connais mal — et dont je peux même ne pas avoir pas les sources sur moi.

Dans ces types de situations, j’ai besoin d’un outil qui :

• Comprenne du code-source : il doit être capable de déterminer ce qui est une fonction, ce qui est une variable, une classe, …
• Soit accessible en ligne via un navigateur, puisque je peux ne pas avoir le code de l’application sur le PC que j’utilise à un instant donné,
• Soit extrêmement rapide à répondre !
• Et soit capable d’indexer plusieurs projets, éventuellement sur plusieurs branches Git ou SVN différentes.

J’ai découvert il y a plusieurs années lxr.php.net, qui permet d’effectuer des recherches dans le code source de chacune des branches stables de PHP (et je l’utilise régulièrement lors que je travaille au développement ou debugagge d’extensions PHP !). Il s’agit d’une instance d’un logiciel nommé OpenGrok (les sources sont sur Github), basé sur Lucene, et que j’ai depuis déployé plusieurs fois sur mes machines personnelles ou professionnelles.

Installation d’OpenGrok

OpenGrok requiert quelques composants :

• Une version récente de JAVA (1.6 ou 1.7)
• Un conteneur de servlet (Tomcat, par exemple)
• Exuberant Ctags

Sous Debian “wheezy” 7.1, le tout peut s’installer depuis les repositories officiels :

sudo apt-get install exuberant-ctags tomcat6

Si vous avez la JRE d’Oracle installée (typiquement, parce qu’un autre logiciel la requiert), OpenGrok fonctionnera aussi très bien avec.

En fonction des projets à indexer, il pourra aussi être utile d’installer les clients SVN, git, … qui permettront d’extraire les sources à indexer.

Au besoin, le port d’écoute de Tomcat peut être modifié dans le fichier /etc/tomcat6/server.xml — j’utilise généralement le port 8181 pour mon instance d’OpenGrok, le port 8080 (par défaut) étant souvent déjà pris par un autre logiciel. Pour cela, modifiez le bloc suivant :

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           URIEncoding="UTF-8"
           redirectPort="8443" />

En fonction du port que vous avez choisi, et après éventuel redémarrage via sudo /etc/init.d/tomcat6 restart, Tomcat doit être accessible en HTTP (URL à adapter, bien sûr) :

http://192.168.0.13:8181/

Il ne reste plus qu’à télécharger OpenGrok et décompresser le fichier obtenu :

cd /opt/
sudo wget http://java.net/projects/opengrok/downloads/download/opengrok-0.11.1.tar.gz
sudo tar xf opengrok-0.11.1.tar.gz
sudo rm opengrok-0.11.1.tar.gz
sudo mv opengrok-0.11.1 opengrok

Ensuite, déployons l’application web :

cd opengrok/bin
sudo ./OpenGrok deploy

Puis, redémarrons le serveur :

sudo /etc/init.d/tomcat6 restart

Et enfin, l’interface web d’OpenGrok devrait désormais être accessible, sous l’URL /source/ :

http://192.168.0.13:8181/source/

Ce qui doit donner quelque chose de ce type :

Puisque nous n’avons lancé aucune indexation (cf la date d’indexation au 1er janvier 1970 en bas de la page), le logiciel n’est pour l’instant pas encore très utile, et n’affiche aucun projet.

Indexer du code-source avec OpenGrok

Une fois OpenGrok installé, il faut indexer le code-source au sein duquel vous souhaitez pouvoir naviguer et effectuer des recherches.

Pour cela, le code des projets que vous souhaitez indexer doit se trouver sous un même répertoire ; et l’indexation sera lancée sur ce répertoire. Notez qu’il n’est pas possible de spécifier une liste de branches à indexer pour un projet ; à la place, à vous de cloner le projet autant de fois que nécessaire, et de positionner chaque extraction sur la branche souhaitée (ça demande un peu plus de travail de mise en place des sources à indexer, mais ça offre aussi plus de souplesse — et OpenGrok se concentre sur son rôle : l’indexation).

A titre d’exemple, récupérons vers $HOME/projects les sources de trois projets, et positionnons-nous sur les branches qui nous intéressent :

mkdir $HOME/projects

# Sources de PHP master
git clone https://git.php.net/repository/php-src.git $HOME/projects/php-src

# Symfony 1.4
git clone https://github.com/symfony/symfony1.git $HOME/projects/symfony-1.4
cd $HOME/projects/symfony-1.4

# symfony 2.3
git clone https://github.com/symfony/symfony.git $HOME/projects/symfony-2.3
cd $HOME/projects/symfony-2.3
git checkout -b 2.3 origin/2.3

Ensuite, créons le répertoire que OpenGrok utilisera pour stocker les données résultant de l’indexation (je souhaite pouvoir lancer l’indexation avec le compte utilisateur user, d’où le chown) :

sudo mkdir /var/opengrok
sudo chown user:user /var/opengrok

Et enfin, lançons l’indexation du contenu de $HOME/projects, à l’aide de la commande suivante :

/opt/opengrok/bin/OpenGrok index $HOME/projects

L’indexation peut durer quelques temps, et consommer pas mal de ressources. Pour indexer les sources récupérées plus haut, sur une VirtualBox dual-core à 2GB de RAM (sur un système physique Core 2 Quad à 2.8 GHz, 8 GB de RAM, et SSD), il a fallu environ 5 minutes et demies — mais sur des projets beaucoup plus gros, j’ai déjà vu l’indexation durer plus d’une heure !

Utiliser l’interface web d’OpenGrok pour naviguer dans les sources indexées

Une fois l’indexation terminée, la liste des projets (les sous-répertoires de celui sur lequel l’indexation a été lancée) remonte sous forme d’une liste, en haut à droite de l’interface d’OpenGrok :

Le lien xhref permet de naviguer dans l’arborescence du code des différents projets :

Les champs de formulaire en haut à gauche, quant à eux, permettent d’effectuer des recherches de différents types dans les projets sélectionnés :

• Full Search : pour effectuer une recherche textuelle.
• Definition : pour chercher des définitions de variables, fonctions, …
• Symbol : pour rechercher des utilisations de variables, fonctions, …
• File Path : pour spécifier sous quel chemin rechercher.
• History : pour effectuer une recherche dans l’historique de commits.

Les résultats de recherche sont cliquables, avec de multiples liens :

• H donne accès à l’historique du fichier,
• A donne accès aux annotions : pour chaque ligne est indiquée le commit et son auteur (revient à un git blame ou svn blame),
• D permet d’accéder au fichier brut,
• Cliquer sur le nom du fichier permet de le consulter,
• Et enfin, cliquer sur la ligne de code en partie droite permet d’accéder directement à celle-ci.

Une fois que vous êtes sur un fichier, chaque mot-clef, chaque nom de variable, chaque constante, chaque nom de fonction, … tout est cliquable, et permet soit de naviguer vers les définitions (typiquement, pour une fonction ou une variable définie dans le même fichier) ou de lancer des recherches complémentaires.

D’ailleurs : si vous avez cliqué sur un nom de fichier, la recherche sera lancée en utilisant celui-ci comme nom de fichier ; si vous avez cliqué sur nom de fonction, la recherche sera lancée sur la définition de celle-ci ; et ainsi de suite : OpenGrok, lors de sa phase d’indexation, a compris la syntaxe du code-source, et fait donc bien plus qu’un simple grep !

Quelques exemples de recherches et de résultats

Le premier champ Full Text permet d’effectuer une recherche textuelle dans les projets indexés. Je l’utilise parfois pour rechercher, dans les sources de PHP, des définitions de fonctions (qui, fréquemment, sont construites avec une syntaxe de la forme PHP_FUNCTION(nom_de_fonction)) :

Le champ Definition permet de rechercher des définitions (de variables, fonctions, …) correspondant à un motif. Par exemple, si nous saisissons zend_*_parameters dans ce champ, en sélectionnant les sources de PHP comme projet, nous obtiendrons en retour des liens vers les endroits où les fonctions correspondant à ce motif sont définies :

A l’inverse, le champ Symbol permet de rechercher les usages d’un motif (pour une fonction, ses appels ; pour une variable, ses utilisations). Par exemple, en recherchant strlen dans les sources de symfony 2.3, nous obtiendrons un grand nombre de résultats :

Le champ File Path permet de spécifier dans quels chemins rechercher — je l’utilise principalement pour limiter les résultats d’une recherche à un sous-ensemble des sources du projet au sein duquel j’effectue une recherche spécifiée via les autres champs. Par exemple, pour rechercher les utilisations de la fonction strlen() dans les sources de l’extension PDO de PHP, je pourrais utiliser quelque chose de ce type :

Pour finir, le champ History permet de rechercher dans l’historique de commits d’un projet. Par exemple, recherchons la chaîne “bug #55399” (entourée de double-quotes) en utilisant le champ History, sur les sources de PHP. Le résultat obtenu est alors le suivant :

Ces champs peuvent contenir des wildcards comme * pour plusieurs caractères, et ? pour un seul caractère. Ils peuvent bien entendu être combinés, et utilisés pour rechercher sur un seul ou sur plusieurs projets, sélectionnés en partie droite de l’écran.

Pour plus d’informations quant à la syntaxe et aux options utilisables dans les requêtes de recherche, consultez l’URL /help.jsp de votre instance d’OpenGrok :

Quelques conseils, notes, et renvois au manuel formel

Pour finir, voici un peu en vrac quelques conseils et quelques notes — certaines fortement tirées de la documentation, et pas toujours mises en pratique sur mes propres instances d’OpenGrok ^^

Quelques conseils

Comme je le disais un peu plus haut, OpenGrok ne gère pas l’indexation de différentes branches d’un projet, ni la mise à jour de projets depuis votre système de contrôle de sources. A la place, il se concentre sur son boulot : l’indexation. Cela signifie que c’est à vous de mettre en place les projets à indexer, à raison d’un répertoire par projet, en-dessous du répertoire parent de l’indexation.

Pour éviter tout risque d’erreur et automatiser cela, j’ai tendance à utiliser un simple shell-script, qui pull tour à tour les différents projets que je souhaite indexer ainsi que leurs différentes branches, et lance ensuite l’indexation en elle-même.

Sur de gros projets, l’indexation peut durer un bon moment en consommant pas mal de ressources ; j’ai donc l’habitude de lancer ce script d’indexation par cron, la nuit ou le week-end (cela dit, si l’indexation de vos projets est rapide, ça peut aussi tourner pendant une pause café ou entre les midis, et sauver un pingouin en évitant de laisser le PC allumé la nuit).

Les extractions des différents projets et des différentes branches, ainsi que les indexes générés par OpenGrok, peuvent finir par prendre pas mal d’espace disque ; prévoyez donc de les placer sur un disque volumineux — si vous avez un HDD et un SSD, il est probablement peu utile de mettre tout ça sur le SSD ;-)

Aussi : j’ai tendance à indexer une extraction propre de projets, et jamais mon espace de travail courant (qui est souvent positionné sur une branche de développement, pas forcément “propre” au moment où l’indexation est susceptible de se lancer).

Et enfin : en fonction des projets, vous voudrez peut-être récupérer des dépendances externes (par exemple, via composer), ou effacer des fichiers sur lesquels vous n’aurez jamais besoin d’effectuer de recherche (par exemple, des fichiers de données ; ou, des fois, les tests unitaires), avant de lancer l’indexation.

Modifier le répertoire de données

Pour stocker les données d’OpenGrok (résultat de l’indexation) ailleurs que dans le répertoire par défaut /var/opengrok, renseignez un autre chemin via la variable d’environnement OPENGROK_INSTANCE_BASE ; par exemple, pour lancer l’indexation :

OPENGROK_INSTANCE_BASE=/mnt/data/opengrok \
    /opt/opengrok/bin/OpenGrok index $HOME/projects

Considérant que cela changera l’emplacement du fichier de configuration, vous aurez à créer un lien symbolique entre l’emplacement par défaut, et celui que vous venez de spécifier :

ln -s /mnt/data/opengrok/etc/configuration.xml \
    /var/opengrok/etc/configuration.xml 

Plus d’informations sont disponibles dans le fichier README.txt.

Personnalisez la page d’index !

Par défaut, la page d’index d’OpenGrok n’est pas particulièrement jolie — le lien vers xhref est fort utile, mais il manque un élément majeur : un lien clairement visible vers la documentation, la syntaxe à utiliser pour effectuer des recherches un peu poussées.

La page utilisée pour l’instance OpenGrok des sources de PHP est simple, mais plutôt sympa : elle fournit des liens directs vers les arborescences des différentes branches (y compris des moteurs autres que l’implémentation de php.net, comme HHVM), et, surtout, des liens vers la syntaxe à utiliser !

Pour savoir comment personnaliser cette page, cherchez index.html dans le fichier README.txt.

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.

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.

Toutes les fin de mois¹, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou, qui s’en occupe depuis quelques mois :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.

Lors de l’Apéro du 24 juillet 2013, j’ai eu l’occasion de donner une rapide présentation, où j’ai parlé des nouveautés apportées par PHP 5.5, la dernière version stable de notre langage de prédilection, qui a été publiée fin juin.

Les slides que j’ai utilisés comme support sont disponibles en ligne² : PHP 5.5 : slides de ma présentation à l’AperoPHP lyonnais du 24 juillet.

Et puisque j’ai eu plusieurs discussions à ce sujet après la présentation :

• Je publie tous les mois, sur ce blog, une synthèse de la mailing-list internals@ — la mailing-list des développeurs de PHP ; les articles correspondant sont taggés @internals.
• Les articles de mon blog sont bien sûr disponibles via un flux RSS ;-)