Pascal MARTIN (n+1).zéro

Il y a un peu plus d’un mois, j’écrivais que j’étais en train de travailler sur un livre, en français, présentant le développement d’extensions PHP.

Aujourd’hui¹, je viens de publier la première version de ce livre : Développer une Extension PHP.

_{Ce livre est disponible aux formats PDF/EPUB/MOBI², sans DRM.
Le prix est exprimé en dollars US — au 01/12, 1$ = 0.736€.}

À mi-chemin entre une volonté de publier un ensemble complet et la philosophie leanpub³ qui souhaite que les auteurs publient au plus tôt, j’ai choisi d’attendre d’avoir suffisamment de contenu pour que, dès cette première version, ce livre vous aide à mettre en place une extension utile — tout en ayant encore quelques concepts importants à couvrir et plusieurs chapitres à rédiger.

Aujourd’hui, les 225+ pages publiées couvrent les sujets suivants (pour vous donner une idée du style du livre, un aperçu est téléchargeable) :

• Création d’une première extension : ce premier chapitre explique comment créer le squelette d’une extension basique, quels fichiers sources sont requis, et quelles structures de données et déclarations sont nécessaires.
• Environnement de développement : ce chapitre montre comment compiler une version de PHP orientée développement d’extensions et quelles sont les informations qu’elle nous apporte. J’en ai profité pour présenter comment configurer Eclipse CDT pour obtenir un environnement de développement avec débugger graphique.
• Écrire une fonction : les fonctions sont au cœur de PHP et de ses extensions. Nous verrons ici, entre autres, comment recevoir des paramètres et retourner une valeur. Ce sujet est abordé au travers de deux chapitres, le second intégrant des concepts supplémentaires, comme la réception de zval en paramètres, les fonctions attendant un nombre d’arguments variable, ou encore le type-hinting.
• zval : les variables de PHP : les variables de PHP sont représentées, en interne, par une structure nommée zval. Ce chapitre nous montrera comment en créer, les lire et les manipuler.
• HashTable et tableaux : la structure HashTable est utilisée par PHP pour stocker un ensemble de données, comme un tableau. Elle est tellement importante pour PHP qu’elle est fréquemment utilisée en interne, et que de nombreuses fonctions permettent de la manipuler.
• Configuration par fichier .ini : le fichier php.ini représente, pour PHP et pour ses extensions, le standard de configuration permettant aux utilisateurs d’influencer sur leur comportement. Ce chapitre présentera comment exploiter au mieux cette possibilité de paramétrage.
• Tests automatisés : vous n’envisageriez pas de développer une extension sans tests automatisés ? Moi non plus !
• Quelques points divers : ce chapitre regroupe quelques points intéressants, mais qui ne méritaient pas à un chapitre à eux seuls, comme la déclaration de variables super-globales, de constantes, ou la personnalisation de phpinfo(). Cet ensemble est lui aussi reproduit intégralement dans l’aperçu disponible au téléchargement.

Profitant du fait que ce livre soit diffusé en formats numériques, de nouveaux chapitres arriveront par le biais de mises à jour.

J’ai en particulier déjà commencé à travailler sur les points suivants — j’ai bien avancé sur les deux premiers, et j’ai tout juste attaqué le développement des exemples pour le troisième :

• Gestion de la mémoire
• Erreurs et Exceptions
• Classes et objets

Il ne fait aucun doute que des corrections et/ou améliorations diverses et variées se glisseront dans les différentes mises à jour, en fonction de vos retours et suggestions ;-)

Notez aussi que chaque mise à jour sera bien entendu rendue disponible gratuitement, via un simple téléchargement, aux lecteurs ayant déjà acheté le livre.

En septembre 2011, j’ai posté pour la première fois un article où je présentais quelques statistiques à propos des versions de PHP utilisées sur quelque chose comme 800,000 serveurs web. A ce moment là, il y a plus de deux ans, PHP 5.2 était, de loin, la version de PHP la plus utilisée, PHP 5.3 n’arrivant que loin derrière, et PHP 4 était encore largement trop utilisé.

En janvier de cette année, j’ai rédigé le sixième article de cette série. PHP 5.2 représentait alors encore 45.5% des 2.2 million d’hôtes PHP identifiés, mais PHP 5.3 arrivait presque à égalité, avec 40.8%. En parallèle, PHP 5.5 était en pleine phase de versions alpha.

Dix mois après, alors que l’année 2013 va bientôt toucher à sa fin, où en sommes-nous ?

Les données présentées dans cet article ont été collectées le week-end du 2 novembre 2013. Les versions stables de PHP sont 5.3.27 (PHP 5.3 ayant atteint son EOL en juillet, et ne recevra plus que des correctifs de sécurité — jusque juillet 2014), PHP 5.4.21 (PHP 5.4 est aujourd’hui la version dite “old-stable”), et PHP 5.5.5 (PHP 5.5 ayant été déclarée “stable” le 20 juin 2013). PHP 5.2 n’est quant à elle plus supportée depuis bientôt trois ans.

Sommaire :

• Quelques mots sur la méthode
• Quelques chiffres
  • Réponses PHP
  • Serveurs Web
• Versions majeures de PHP
• Versions mineures de PHP
• Versions releases de PHP 5.x
• Evolution

Quelques mots sur la méthode

Pour faire simple¹, j’ai récupéré une liste de plus de 10.3 millions de noms de domaines, issus principalement :

• Du top 1 million d’Alexa (chargé plusieurs fois à quelques mois/années d’écart, ce qui donne maintenant bien plus d’un million de noms de domaines),
• Du top 1 million de Quancast (là aussi, chargé plusieurs fois à quelques mois d’écart),
• Des liens externes de Wikipedia de plusieurs langues (environ 3 millions de noms de domaines — certains correspondant à des sites un peu anciens et pas vraiment mis à jour),
• De l’export mis à disposition par l’Export Open Directory (environ 2 millions de noms de domaines — même remarque),
• Et de quelques résultats de recherche google (quelques milliers de noms de domaines — encore).

Ensuite, pour chacun de ces noms de domaines, j’ai effectué une requête HTTP HEAD sur domaine.tld, en me rabattant sur www.domaine.tld si la première requête échouait.

Après cela, je me suis généralement² basé sur l’en-tête HTTP X-Powered-By renvoyée par le serveur, pour en extraire le nom de logiciel ayant servi à générer la page, ainsi que sa version. Dans les cas où cette en-tête n’existe pas, ou ne contient pas d’information exploitable, je me suis rabattu sur l’en-tête Server.

Pour rappel, et en ne prenant que quelques exemples relativement typiques, les en-têtes HTTP renvoyées par le serveur, dans le cas de pages générées par PHP et sur un serveur exposant la version de PHP utilisée, ressemblent souvent à quelque chose de ce type (pour www.php.net qui expose à la fois une en-tête Server et une en-tête X-Powered-By) :

Server: nginx/1.4.1
X-Powered-By: PHP/5.5.4-1

ou (pour www.compuware.com qui n’expose que la première) :

Server: Apache/2.2.13 (Win32) Communique/4.1.0 PHP/5.4.15

A partir de là, extraire le numéro de la version de PHP utilisée est une opération relativement aisée…

Pour ceux qui voudraient plus de détails, je vous invite à lire deux commentaires romans que j’avais postés suite à l’article de janvier, en réponses à quelques questions qui m’avaient été posées : le premier, et le second.

Quelques chiffres

Réponses PHP

Sur les 9.3 millions de requêtes HTTP effectuées sur les noms de domaines que j’ai testés, environ 26% des réponses ont été identifiées comme générées par du PHP³.

Plus précisément, j’ai identifié 2,459,698 réponses comme correspondant à du PHP.

Avec ce nombre relativement conséquent de réponses, les statistiques présentées plus bas devraient avoir des chances d’être à peu près correctes, ou, tout au moins, de donner des résultats et chiffres relativement proches de la réalité…

Serveurs Web

Cela dit, avant d’entrer dans les détais des versions de PHP, voici la liste des Serveurs Web les plus fréquemment identifiés lors de ma collecte de données :

• Apache : 5,648,351 — 65.14%
• IIS : 1,448,074 — 16.70%
• nginx : 687,779 — 7.93%
• Autres : 419,654 — 4.84%
• GSE : 227,918 — 2.63%
• Oversee Turing v1.0.0 : 85,439 — 0.99%
• LiteSpeed : 78,025 — 0.90%
• cloudflare-nginx : 75,506 — 0.87%

Ou, sous forme d’un graphe :

On ne constate pas de révolution par rapport à janvier 2012 ou à ce début d’année :

• Apache continue d’arriver en tête, puisqu’il sert pas loin de 2/3 des pages interrogées,
• IIS est toujours en seconde place,
• Et nginx conserve la troisième position.

Cela dit, il est intéressant de noter qu’Apache perd petit à petit des parts de marché (2.5% de moins en un an et dix mois), alors que nginx est en constante progression (2.5% de plus sur la même période).

Versions majeures de PHP

Commençons par les versions majeures de PHP, en prenant en compte les résultats qui ont été identifiés comme correspondant à une version supérieure ou égale à 3, et inférieure ou égale à 6⁴.

Mes tests ont remonté le nombre suivant de domaines sur chaque version majeure de PHP :

• PHP 3 : 561 — 0.02%
• PHP 4 : 144,853 — 5.89%
• PHP 5 : 2,314,115 — 94.09%
• PHP 6 : 23 — 0.00%

Sous forme d’un graphe, qui peut être plus parlant pour certains et permet de voir en un clin d’œil quelle est la version majeure de PHP la plus répandue, cela donne :

On notera que, fort heureusement, PHP 5 est la version majeure la plus répandue — on en arrive d’ailleurs enfin à un point où cette comparaison de versions majeures n’est plus réellement intéressante !

Tout de même, pour le petit côté historique :

• Presque fin 2013, on a encore quelques centaines de sites, sur 9.3 millions, qui tournent encore sur du PHP 3⁵,
• PHP 4 n’a toujours pas vraiment disparue, alors que cela fait des années que cette version n’est plus du tout maintenue (PHP 4.4.9, publiée en Août 2008, était annoncée comme étant la dernière version de PHP 4.x),
• Et enfin, PHP 6 (qui, pour rappel, n’a jamais vu une version ne serait-ce qu’alpha être publiée — et a été mise à mort il y a maintenant bien longtemps) est encore utilisée en production sur quelques dizaines de sites⁶…

Versions mineures de PHP

Si on passe aux versions mineures de PHP, toujours pour PHP >= 3.x et PHP <= 6.x, et en ne conservant que les versions qui sont remontées 10 fois ou plus, on obtient les données suivantes :

• PHP 3.0 : 551 — 0.02%
• PHP 3.2 : 10 — 0.00%
• PHP 4.0 : 1,190 — 0.05%
• PHP 4.1 : 2,764 — 0.11%
• PHP 4.2 : 2,522 — 0.10%
• PHP 4.3 : 30,464 — 1.24%
• PHP 4.4 : 107,913 — 4.39%
• PHP 5.0 : 3,602 — 0.15%
• PHP 5.1 : 55,279 — 2.25%
• PHP 5.2 : 845,705 — 34.38%
• PHP 5.3 : 1,198,630 — 48.73%
• PHP 5.4 : 197,552 — 8.03%
• PHP 5.5 : 13,329 — 0.54%
• PHP 5.6 : 10 — 0.00%
• PHP 6.0 : 22 — 0.00%

Et sous forme graphique :

Enfin ! Pour la première fois depuis que j’ai commencé à rédiger ce type d’articles, PHP 5.3 est passé devant PHP 5.2, ce qui signifie que PHP 5.3 figure désormais en première place \o/.

Pas trop tôt, considérant que PHP 5.3, qui a été déclarée stable en juin 2009, a atteint son EOL en juillet 2013, et ne recevra à l’avenir plus que des mises à jour de sécurité (et encore, seulement jusque juillet 2014, normalement) — et que PHP 5.2 est arrivé à sa fin de vie en décembre 2010, il y a presque trois ans donc…

La version aujourd’hui marquée comme old stable, PHP 5.4, publiée en mars 2012, en est quant à elle à tout juste 8%. Moins de 10% plus d’un an et demi après son passage en stable, encore une fois, montre bien que les nouvelles versions de PHP ne sont pas installées aussi vite qu’elles pourraient (et gagneraient à) l’être.

PHP 5.5, qui est la version stable de cette fin d’année, puisqu’elle a été publiée en juin 2013, fait une timide apparition dans ce classement, avec un petit demi-pourcent un peu moins de six mois après sa sortie.

Pour l’annecdote : sur les 10 serveurs qui remontent comme tournant sous PHP 5.6, 8 exposent un numéro de version impossible valant fort étrangement PHP/5.6.7_00:00, et deux (dont par exemple www.phpro.org) s’identifient réellement comme PHP/5.6.0-dev (qui, en ce moment, correspond à une compilation de PHP depuis la branche master).

Versions releases de PHP

Et enfin, si on descend au niveau des versions release de PHP 5.x⁷, en ne conservant que les versions qui remontées 100 fois ou plus, on obtient les données suivantes (à raison d’en gros une release par mois sur deux branches maintenues en parallèle, cette liste de versions se fait un peu longue) :

• Pour PHP 5.0 :
  • 5.0.2 : 187 — 0.01%
  • 5.0.3 : 390 — 0.02%
  • 5.0.4 : 2,380 — 0.10%
  • 5.0.5 : 583 — 0.03%
• Pour PHP 5.1 :
  • 5.1.1 : 196 — 0.01%
  • 5.1.2 : 2,675 — 0.12%
  • 5.1.3 : 1,562 — 0.07%
  • 5.1.4 : 1,379 — 0.06%
  • 5.1.5 : 146 — 0.01%
  • 5.1.6 : 49,312 — 2.13%
• Pour PHP 5.2 :
  • 5.2.0 : 11,837 — 0.51%
  • 5.2.1 : 3,249 — 0.14%
  • 5.2.2 : 976 — 0.04%
  • 5.2.3 : 4,177 — 0.18%
  • 5.2.4 : 24,344 — 1.05%
  • 5.2.5 : 18,898 — 0.82%
  • 5.2.6 : 94,221 — 4.07%
  • 5.2.8 : 11,687 — 0.51%
  • 5.2.9 : 39,850 — 1.72%
  • 5.2.10 : 26,477 — 1.14%
  • 5.2.11 : 14,919 — 0.64%
  • 5.2.12 : 10,155 — 0.44%
  • 5.2.13 : 24,010 — 1.04%
  • 5.2.14 : 23,667 — 1.02%
  • 5.2.15 : 2,126 — 0.09%
  • 5.2.16 : 7,507 — 0.32%
  • 5.2.17 : 527,282 — 22.79%
  • 5.2.18 : 107 — 0.00%
• Pour PHP 5.3 :
  • 5.3.0 : 2,087 — 0.09%
  • 5.3.1 : 2,626 — 0.11%
  • 5.3.2 : 46,730 — 2.02%
  • 5.3.3 : 238,690 — 10.32%
  • 5.3.4 : 2,301 — 0.10%
  • 5.3.5 : 14,398 — 0.62%
  • 5.3.6 : 23,788 — 1.03%
  • 5.3.7 : 542 — 0.02%
  • 5.3.8 : 39,915 — 1.73%
  • 5.3.9 : 6,371 — 0.28%
  • 5.3.10 : 167,133 — 7.22%
  • 5.3.11 : 671 — 0.03%
  • 5.3.12 : 305 — 0.01%
  • 5.3.13 : 29,505 — 1.28%
  • 5.3.14 : 10,964 — 0.47%
  • 5.3.15 : 16,500 — 0.71%
  • 5.3.16 : 20,822 — 0.90%
  • 5.3.17 : 16,679 — 0.72%
  • 5.3.18 : 22,831 — 0.99%
  • 5.3.19 : 20,143 — 0.87%
  • 5.3.20 : 14,115 — 0.61%
  • 5.3.21 : 84,397 — 3.65%
  • 5.3.22 : 17,214 — 0.74%
  • 5.3.23 : 30,510 — 1.32%
  • 5.3.24 : 25,176 — 1.09%
  • 5.3.25 : 31,389 — 1.36%
  • 5.3.26 : 66,989 — 2.90%
  • 5.3.27 : 245,825 — 10.62%
• Pour PHP 5.4 :
  • 5.4.0 : 803 — 0.03%
  • 5.4.1 : 107 — 0.00%
  • 5.4.3 : 1,361 — 0.06%
  • 5.4.4 : 28,436 — 1.23%
  • 5.4.5 : 916 — 0.04%
  • 5.4.6 : 6,896 — 0.30%
  • 5.4.7 : 3,296 — 0.14%
  • 5.4.8 : 2,233 — 0.10%
  • 5.4.9 : 7,947 — 0.34%
  • 5.4.10 : 2,233 — 0.10%
  • 5.4.11 : 4,174 — 0.18%
  • 5.4.12 : 4,461 — 0.19%
  • 5.4.13 : 4,156 — 0.18%
  • 5.4.14 : 5,851 — 0.25%
  • 5.4.15 : 4,327 — 0.19%
  • 5.4.16 : 6,520 — 0.28%
  • 5.4.17 : 17,854 — 0.77%
  • 5.4.18 : 5,570 — 0.24%
  • 5.4.19 : 21,202 — 0.92%
  • 5.4.20 : 23,563 — 1.02%
  • 5.4.21 : 45,548 — 1.97%
• Pour PHP 5.5 :
  • 5.5.0 : 1,156 — 0.05%
  • 5.5.1 : 1,422 — 0.06%
  • 5.5.2 : 782 — 0.03%
  • 5.5.3 : 5,441 — 0.24%
  • 5.5.4 : 2,692 — 0.12%
  • 5.5.5 : 1,832 — 0.08%

Et sous forme graphique :

Pour résumer :

• Au niveau de PHP 5.1, la version 5.1.6 (qui a été publiée en Août 2006) est toujours un peu représentée ; si j’ai bonne mémoire, c’était la version par défaut sur certaines distributions “pro” (je pense à du Redhat Enterprise, en particulier, ou à CentOS 5.10) il n’y a encore pas si longtemps.
• Pour ce qui est de PHP 5.2 :
  • PHP 5.2.17 (publiée en Janvier 2011) est la version release de PHP la plus utilisée, toutes versions mineures confondues, avec 22.8%. Je suppose qu’on peut se consoler en se disant que même si PHP 5.2 est une vielle version qui ne reçoit même plus de correctif de sécurité (mais comment peut-on continuer à utiliser ça en production ? Et quand on regarde les améliorations apportées par 5.3/5.4/5.5, comment peut-on encore développer en 5.2 ?), il s’agit au moins de la dernière version…
  • PHP 5.2.6, publiée en mai 2008 et version fournie par défaut sous Debian Lenny, représente quant à elle toujours 4%.
• Pour PHP 5.3, trois versions release se distinguent :
  • PHP 5.3.3 remonte sur 10.3% des serveurs identifiés ; c’est notamment la version par défaut sous Debian Squeeze ou sous Centos 6.4
  • PHP 5.3.10 en est à 7.2% ; il s’agit notamment de la version packagée par Ubuntu Precise
  • PHP 5.3.27, la dernière version release de la branche 5.3 (et, sauf faille de sécurité découverte sur les 8 prochains mois, possiblement la dernière version de PHP 5.3), est la version la plus installée de PHP 5.3.x, avec ses 10.6%.
• Passons à PHP 5.4 :
  • PHP 5.4.4 apparaît comme installée sur 1.2% des serveurs identifiés. C’est la version fournie par Debian Wheezy
  • PHP 5.4.21, la dernière release de la branche 5.4, en est elle à quasiment 2%, et est la version la plus représentée de la branche 5.4
• Enfin, pour PHP 5.5, aucune version ne semble réellement se distinguer — mais il faut admettre que l’échantillon est un peu faible, même plusieurs mois après le passage de 5.5 en stable…
  • Une explication possible serait qu’aucune distribution orientée serveur ne vient aujourd’hui avec PHP 5.5 par défaut ?
  • Mais les choses semblent aller dans le bon sens, puisque PHP 5.5 est fournie par Debian Jessie (qui n’est pas encore stable), ou par Ubuntu 13.10 Saucy (sortie il y a peu).

Évolution

Fidèle à mon habitude, je ne ferai pas une longue analyse sur le pourquoi du comment des chiffres que j’ai présentés ici : libre à vous de commenter sur le trop grand usage de versions complètement obsolètes, et le manque de mise à jour que l’on peut, malheureusement, trop souvent constater…

Cela dit, puisque ce n’est pas la première fois que j’effectue ce processus de collecte de statistiques à propos des versions de PHP utilisées, je me suis dit qu’il pouvait être intéressant de tracer un graphe représentant l’évolution de ces utilisations.

Le graphe reproduit ci-dessous présente donc l’évolution de l’utilisation des versions mineures de PHP, depuis septembre 2011⁸ :

J’ai essayé de mettre en évidence les versions les plus à même de nous concerner en ce moment (à savoir, PHP 5.2, 5.3, 5.4, et 5.5), ainsi que, dans une moindre mesure les deux autres versions les plus utilisées (autrement dit, PHP 4.4 et 5.1).

Le point le plus intéressant ici est sans aucun doute que, enfin, PHP 5.3 figure en première place, ayant finalement réussi à dépasser PHP 5.2 ! On pouvait s’y attendre en regardant les courbes de janvier 2013, août 2012, ou même avril 2012, mais c’est enfin une réalité \o/.

PHP 5.4 commence à se faire une petite place et à se détacher du groupe de courbes figurant tout en bas du graphique. Considérant que PHP 5.3 a atteint son EOL et ne recevra plus que des correctifs sécurité (et seulement jusqu’à juillet 2014 !), et que PHP 5.4 est déjà la version old-stable, idéalement, il serait dès maintenant temps de passer à PHP 5.5, quitte à sauter l’étape de PHP 5.4. Les migrations 5.3 -> 5.4 et 5.4 -> 5.5 sont plus faciles que la migration 5.2 -> 5.3, en particulier grâce au cycle de releases plus rapide adopté ces dernières années.

PHP 5.5, la version actuellement stable de PHP, est à peine visible… A nous de faire en sorte que cela change !

Après septembre et ses 625 mails, voici mon dépilage d’internals@ pour le mois d’octobre 2013, qui est arrivé à un total de 562 messages.

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) :

Depuis quelques mois, de nombreuses RFC ont été rédigées, visant PHP 5.6.

David Soria Parra, RM de PHP 5.4 et co-RM de PHP 5.5, a annoncé que, pour s’en tenir au planning prévu, PHP 5.6 devrait sortir en version stable dans 10 mois (c’est une coïncidence, mais cela permettrait à PHP 5.6 d’être inclue dans la prochaine Debian Stable, prévue pour dans 14 mois) — et que les dernières versions sorties avaient montré qu’il fallait environ 5 mois pour stabiliser une version et passer les phases alpha/bêta/RC.

Son mail indiquait qu’il était donc temps de commencer à réfléchir à l’organisation de la sortie de PHP 5.6, ainsi que de penser à trouver un RM pour cette version, afin qu’il ait déjà le temps d’apprendre sur PHP 5.5 — par la suite, plus de précisions sur le rôle du RM ont été données. Après quelques discussions, il est ressorti que les deux RM de PHP 5.6 seront Julien Pauli et Ferenc Kovacs.

En toute fin de mois dernier, Joe Watkins a annoncé avoir commencé à travailler sur la RFC: Nested Classes, qui pourrait par exemple être pratique pour les développeurs de bibliothèques ne souhaitant pas exposer certaines classes censées être utilisées uniquement en interne.

L’idée étant un peu complexe et demandant probablement plus de réflexion, Joe Watkins a fini par se demander si elle n’attendrait pas PHP 5.7, afin de ne pas arriver à une fonctionnalité pas assez réfléchie pour PHP 5.6.

En parallèle, il a annoncé l’ouverture des votes pour la RFC: Anonymous Classes — qui a finalement a été rejetée, avec 23 votes contre pour 9 votes pour.

Michael Wallner a noté que les variables super-globales $_GET et $_POST pouvaient être source de confusion, puisqu’elles peuvent être renseignées plus ou moins indépendamment de la méthode HTTP utilisée (Johannes Schlüter a par la suite fait remarquer que ces noms de variables correspondaient à ce qui est utilisé pour les formulaires HTML). Il a donc proposé de renommer $_GET en $_QUERY, et $_POST en $_FORM ; et, au passage, d’exposer les analyseurs de corps de requête à l’espace utilisateur, et de les déclencher indépendamment de la méthode HTTP utilisée.

Comme l’a rapidement fait remarquer Alexey Zakhlestin, ce renommage de variables casserait la quantité énorme de code les utilisant — mais les deux autres idées seraient intéressantes. Il n’était d’ailleurs pas le seul de cet avis.

Notons tout de même qu’exposer des parsers supplémentaires, si ce choix est retenu, doit être fait avec prudence : comme l’a rappelé Nikita Popov, cette idée a déjà mené à des vulnérabilités dans d’autres langages.

Joe Watkins a lancé un sujet de conversation, où il essayait d’attirer l’attention sur le fait que les assertions de PHP sont assez pauvres — d’ailleurs, est-ce que cela ne serait pas une raison pour laquelle elles sont si peu utilisées ?

Après quelques discussions tournant notamment autour de la levée d’erreur ou d’exceptions, Joe Watkins a annoncé avoir rédigé la RFC: Expectations¹. Avec 50 mails dans la conversation, sans compter les échanges sur la discussion précédente, c’est visiblement le sujet qui a le plus attiré l’attention ce mois-ci.

Les premiers retours ont semblé être plutôt positifs, même si l’introduction d’un nouveau mot-clef expect pourrait causer des problèmes de compatibilité.

Suite à un mail où Derick Rethans faisait remarquer que la RFC n’apportait aucune indication quant à l’utilité de cette proposition par rapport à assert(), il a été répondu que la fonctionnalité aujourd’hui apportée par assert() était peu performante, et qu’elle ne pouvait pas être désactivée facilement en environnement de production, assert() étant une fonction et non une construction langage associée à un opcode. Joe Watkins a aussi apporté en réponse des précisions sur l’aspect erreur vs exception.

Les échanges s’étant fait plus rares en fin de mois, il y a des chances que cette RFC soit ouverte au vote sur les prochaines semaines.

Rowan Collins a proposé de marquer la fonction create_function() comme obsolète, considérant que le gros des usages (mais pas tous) pouvaient, depuis PHP 5.3, être remplacés par des utilisations de fonctions anonymes.

En effet, comme l’a souligné Nikita Popov, passer par create_function() est lent, consomme de la mémoire, et introduit parfois un risque en termes de sécurité.

Cela dit, Pierre Joye a répondu que de nombreuses fonctionnalités des versions récentes de PHP permettent d’écrire du code plus propre que celui que nous écrivions par le passé, mais que ce n’était pas une raison suffisante pour lever des notices partout — d’autant plus que create_function() est assez fortement utilisée, et fonctionne. Dans le même temps, supprimer cette fonction (ce qui est une suite logique, une fois qu’elle a été marquée comme obsolète ; mais ce serait pour PHP 5.7 ou plus, donc dans plusieurs années !) serait problématique pour des projets acceptant encore PHP 5.2 — Ryan McCue a ainsi noté que pour Wordpress, en cas de suppression de PHP, cette fonction devrait être ré-implémentée côté utilisateur (ce qui ne l’a pas empéché, sauf erreur d’interprétation de ma part, de trouver la proposition intéressante).

Nikita Popov a annoncé avoir rédigé la RFC: Exceptions in the engine, dont le but est de permettre la levée d’exceptions depuis le moteur de PHP, et de remplacer certaines Fatal Error par des levées d’exceptions.

Il a ensuite répondu à ceux qui s’inquiétaient des possibles impacts au niveau de la compatibilité entre versions de PHP, en soulignant que, quoi qu’il en soit, une Fatal Error ne correspondait déjà pas à un fonctionnement normal ni souhaité d’un programme. Autrement dit, le seul changement qui serait visible correspond à un cas où un script ne fonctionnait déjà pas.

Plusieurs ont indiqué trouver l’idée extrêmement intéressante, voulant même parfois aller plus loin que le remplacement de seulement quelques erreurs fatales — ce qui serait, pour le coup, un gros changement avec un impact massif en termes de compatibilité.

Dans le même temps, certains ont noté qu’il n’était peut-être pas urgent d’effectuer ce type de modification². Le sujet d’une éventuelle version de PHP 6.x a donc recommencé à surgir : il permettrait de mettre en place, petit à petit, ce type de modifications potentiellement impactantes, tout en ne gelant pas l’arrivée de modifications plus mineures via des versions comme PHP 5.6 et 5.7.

Andrea Faulds a annoncé avoir rédigé la RFC: list() Reference Assignment, qui permettrait d’utiliser une syntaxe de ce type :

$array = [1, 2];
list($a, &$b) = $array;

A la place (comme raccourci, donc) de la syntaxe suivante :

$array = [1, 2];
$a = $array[0];
$b = &$array[1];

Cela aidera sans doute ceux d’entre nous qui travaillent sous Windows : Anatol Belski a annoncé que les builds pour Windows d’extensions PECL étaient maintenant référencés directement depuis les pages de chaque extension (par exemple, pour solr ou pour APC) — et ce pour une centaine d’extensions sur les environs 300 hébergées par PECL.

Benjamin Schneider a proposé d’ajouter une nouvelle exception, InvalidStateException, à l’extension SPL (Guilherme Blanco a répondu qu’elle pourrait être nommée IllegalStateException). Levi Morrison a fait remarquer que la partie exceptions de la SPL n’était pas des plus structurées, et qu’il pourrait être intéressant de mener une réflexion plus approfondie avant d’ajouter une nouvelle classe — il existe d’ailleurs la RFC: SPL Improvements sur le sujet depuis 2011, mais elle introduirait pas mal d’incompatibilités ; une seconde RFC, RFC: SPL Improvements: Exceptions se concentre, elle, sur les exceptions.

De son côté, Lior Kaplan a continué à poster régulièrement ses rapports sur l’état des Pull Requests faites sur le projet PHP.

Daniel Lowrey a quant à lui annoncé avoir rédigé la RFC: TLS Peer Verification. Il n’y a pas vraiment eu de retour autour de cette proposition ni des autres points qu’il évoquait dans son mail ; peut-être sur les prochaines semaines ?

La RFC: Extended keyword support dont j’avais parlé le mois dernier a été ouverte aux votes — et a été rejetée. Il est à noter que plusieurs votants ont expliqué pourquoi avoir voté non — ce qui est une bonne chose.

Yasuo Ohgaki a annoncé avoir rédigé la RFC: Make session_regenerate_id()’s delete_old_session parameter required gracefully, en vue d’améliorer la sécurité des sessions.

Andrea Faulds a implémenté les fonctions apache_request_headers() (aussi aliasée sous le nom plus générique getallheaders()) et apache_response_headers() pour le serveur web de test intégré à PHP. Même si ce serveur web n’est pas Apache, ces deux fonctions permettent de le rapprocher des autres SAPI.

Dmitry Stogov a proposé deux patchs éliminant des copies inutiles de variables dans array_merge() et func_get_args(), rendant par exemple la page d’accueil de Wordpress 2% à 4% plus rapide. Voici deux petites optimisations qui pourraient trouver leur place dès PHP 5.5 ! Dans la foulée, il a aussi proposé un patch qui éliminerait quelques appels au Garbage Collector.

Après le départ d’Anthony Ferrara il y a quelques semaines/mois et le retrait des RFC qu’il avait rédigé, Andrea Faulds a annoncé avoir réouvert la RFC: Constant Scalar Expressions. Peu de réaction pour l’instant, mais peut-être dans les prochaines semaines…

Oh, et pour finir, tant que j’y pense et en sortant un peu du sujet : j’ai profité de ce week-end de trois jours pour lancer une collecte de données, qui devrait me permettre de prochainement publier un article “Statistiques de versions de PHP” — le dernier remontant à janvier, il date un peu, et une mise à jour ne peut que faire du bien !

Et pour finir avec un peu d’auto-publicité : si le sujet vous intéresse, vous pouvez demander à être prévenu lorsque je publierai le livre électronique Développer une Extension PHP sur lequel je travaille régulièrement.

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.

Depuis quelques années, j’ai occasionnellement l’occasion de discuter du sujet du développement d’extensions PHP avec des collègues ou d’autres développeurs (lors d’aperos, de conférences, …), et il ressort souvent de la discussion que le sujet est intéressant, que certains d’entre nous ont envie d’essayer, ne serait-ce que pour le plaisir et par curiosité, mais que l’idée semble effrayante et qu’il y a comme un manque de documentation.

En parallèle, je crois que la première fois où j’ai développé une extension était lors d’une demi-journée organisée par l’AFUP Paris en 2011, où le sujet avait été présenté par Julien Pauli et Patrick Allaert¹, sous forme d’une rapide introduction théorique suivie par une après-midi de pratique — et j’avais trouvé ça plutôt sympa.

Depuis, je n’hésite plus à aller fouiller de temps en temps dans le code de PHP², et je me suis rendu compte que, même si je n’avais pas réellement codé en C depuis une petite dizaine d’années³, j’arrivais globalement à comprendre ce qu’il se passe⁴… Et avec le temps qui passe, ça a de plus en plus titillé ma curiosité ^^

J’ai donc fini par m’y mettre de plus en plus, en commençant par le classique “Hello World!” et en avançant petit à petit, tout en me disant qu’il pourrait être intéressant de prendre quelques notes, et de les partager — ce qui me donne aussi une raison de fouiller plus que je n’en ai parfois besoin sur le coup, rendant l’exercice encore plus enrichissant pour moi.

Résultat, j’ai commencé à écrire ce qui est en train de devenir un livre électronique, en français, à propos du développement d’Extensions PHP : en l’état actuel, 10 chapitres sont rédigés (ils représentent 225+ pages, soit 50,000+ mots), et 5 chapitres supplémentaires sont prévus mais pas encore commencés.

Ce livre sera distribué (en PDF/EPUB/MOBI) par le biais du site Leanpub, et en suivant la logique du Manifesto correspondant⁵, je le publierai alors qu’il ne sera pas encore achevé, et le mettrai ensuite à jour au fur et à mesure de l’écriture des évolutions et chapitres suivants, et/ou des corrections éventuelles.

En attendant cette publication prochaine, vous pouvez dès maintenant signaler votre intérêt et demander à être prévenu lors de la publication du livre : Développer une Extension PHP.

Voici quelques informations sur les sujets couverts par les chapitres déjà rédigés, qui devraient vous permettre de faire vos premiers pas dans le développement d’extensions PHP :

• Création d’une première extension : il s’agit du premier chapitre du livre, qui est reproduit intégralement dans l’aperçu disponible au téléchargement. J’y explique comment créer le squelette d’une première extension, quels fichiers sources sont requis, et quelles structures de données et déclarations sont nécessaires.
• Environnement de développement : ce chapitre montre comment compiler une version de PHP orientée développement d’extensions et quelles sont les informations qu’elle nous apporte. J’en ai profité pour présenter comment configurer Eclipse CDT pour obtenir un environnement de développement avec débugger graphique.
• Écrire une fonction : les fonctions sont au cœur de PHP et de ses extensions. Nous verrons ici, entre autres, comment recevoir des paramètres et retourner une valeur. Ce sujet est abordé au travers de deux chapitres, le second intégrant des concepts supplémentaires, comme la réception de zval en paramètres, les fonctions attendant un nombre d’arguments variable, ou encore le type-hinting.
• zval : les variables de PHP : les variables de PHP sont représentées, en interne, par une structure nommée zval. Ce chapitre nous montrera comment en créer, les lire et les manipuler.
• HashTable et tableaux : la structure HashTable est utilisée par PHP pour stocker un ensemble de données, comme un tableau. Elle est tellement importante pour PHP qu’elle est fréquemment utilisée en interne, et que de nombreuses fonctions permettent de la manipuler.
• Configuration par fichier .ini : le fichier php.ini représente, pour PHP et pour ses extensions, le standard de configuration permettant aux utilisateurs d’influencer sur leur comportement. Ce chapitre présentera comment exploiter au mieux cette possibilité de paramètrage.
• Tests automatisés : vous n’envisageriez pas de développer une extension sans tests automatisés ? Moi non plus !
• Quelques points divers : ce chapitre regroupe quelques points intéressants, mais qui ne méritaient pas à un chapitre à eux seuls, comme la déclaration de variables super-globales, de constantes, ou la personnalisation de phpinfo(). Ce chapitre est lui aussi reproduit intégralement dans l’aperçu disponible au téléchargement.

J’ai prévu d’aborder d’autres sujets, pour lesquels je n’ai pas encore commencé la rédaction.
Je pense en particulier aux points suivants :

• Classes et objets
• Travailler avec les flux
• Développer une extension PHP sous Windows
• Les ressources
• Gestion de la mémoire

Une fois le livre publié, il sera mis à jour au fur et à mesure de la rédaction, entre autres, de ces chapitres — l’ordre dans lequel ils figurent ici n’étant en rien indicatif de leur ordre de rédaction.

Pour vous donner une idée de la vitesse à laquelle j’écris : j’ai commencé à réfléchir à ce projet il y a plus d’un an, mais je n’ai commencé à écrire qu’en février 2013, ce qui représente en gros une moyenne d’un chapitre par mois. Cela dit, j’écris à une allure variable, puisque j’ai fait une quasi-pause de plusieurs mois à un moment, alors que j’ai écrit un chapitre en une semaine et deux week-ends à un autre moment ; et sur les 245 jours écoulés depuis la création du repository hébergeant ce projet, j’ai été actif 80 jours (soit 32.7% du temps).

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.

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.