Le forum PHP 2010, qui a eu lieu les 9 et 10 novembre derniers, a accueilli quatre figures emblématiques de la communauté des développeurs de PHP.

Rasmus Lerdorf, le créateur du langage, et Zeev Suraski, l'un des deux pères du Zend Engine, avaient ainsi fait le déplacement jusqu'à Paris.

De plus, Derick Rethans, notamment connu pour avoir développé Xdebug, et Ilia Alshanetsky, qui participe au développement du langage dans sa globalité, ont participé à l'événement, qui fêtait cette année les 15 ans d'existence du langage et les 10 ans de l'AFUP.

J'ai donc profité de cette occasion pour discuter physiquement, avec Rasmus, Derick et Ilia de l'avenir de PHP et du fonctionnement de la communauté des développeurs, sans passer par mes outils de communication habituels que sont IRC et la liste de diffusion des développeurs du langage,  internals@.

Je vous livre donc dans les lignes qui suivent une synthèse de ces discussions très informelles, puisqu'elles ont eu lieu en dehors des conférences.

J'ai ainsi eu au cours de nos conversation la confirmation qu'il y avait 90% de chances pour que Derick Rethans soit le release master de la prochaine version du langage.

Cette version, fruit du travail énorme effectuée par la communauté des développeurs depuis l'abandon du développement de PHP 6, sera certainement nommée PHP 5.4 et sa sortie est prévue pour la première moitié de l'année 2011.

Elle proposera entre autre chose un modèle objet renforcé, via le concept de traits, ainsi que le support de DTrace, la possibilité d’accéder directement aux éléments d'un tableau renvoyé par une fonction ou une méthode, et des améliorations au niveau du support des fonctions anonymes et des fermetures.

Elle donnera également la possibilité de définir le type numérique des arguments des méthodes et des fonctions, et elle proposera l'interface jsonable qui permettra de définir le comportement d'un objet lorsqu'il sera sérialisé au format JSON.

Cependant, tout cela n'a pas été fait au détriment des performances, puisqu'elles sont en nette hausse, grâce à une optimisation poussée de la gestion de la mémoire.

PHP 5.4 sera donc plus rapide, mais surtout beaucoup moins gourmand en mémoire, puisque les tests montrent que suivant le contexte d'exécution, il est susceptible de consommer jusqu'à 30% de mémoire de moins que la précédente version.

Enfin, certains boulets historiques de PHP, comme la directive register_globals, le safe mode ou les magic quotes ont été supprimés, mais en contrepartie, le code existant reposant sur ces fonctionnalités ne fonctionnera plus.

Ilia m'a d'ailleurs indiqué que ce nettoyage devrait se poursuivre avec les prochaines versions, de façon à assainir le langage, mais cependant, cela ne provoquera jamais de cassure brutale de la compatibilité.

La communauté a en effet la volonté de faire cela de manière très progressive afin de permettre une mise à jour en douceur des quelques milliards de lignes de code PHP existantes dans le monde.

Et de plus, le périmètre de cet assainissement n'est pas clairement défini puisque le développement du langage suit à l'heure actuelle une politique très pragmatique.

Ainsi, toute modification ou un évolution doit absolument répondre à une problématique réelle et sérieuse qui ne peut pas être résolue par un autre moyen, tout en ayant un impact minimal sur les performances du langage et ne pas rendre le langage plus complexe.

L'ajout de l'interface jsonable est l'exemple parfait de cette politique, car elle permet de répondre simplement à une problématique concrète dans le monde du développement web d'aujourd'hui, induite l'utilisation massive d'AJAX qui nécessite de faire transiter dans un format simple un volume de données important entre des clients et un serveur.

En conséquence, la décision de supprimer une fonctionnalité jugée comme dangereuse ou comme étant une erreur de conception ne sera prise qu'uniquement en fonction de cet aspect pragmatique.

C'est la raison pour laquelle il y a peu de chances de voir un jour la règle de nommage des fonctions de PHP uniformisée, alors que c'est une demande récurrente des utilisateurs du langage.

En effet, les fonctions concernées fonctionnent parfaitement, et la correction de cet aspect purement esthétique n'est pas jugée comme primordiale, même si Rasmus avoue que s'il en avait la possibilité, il réécrirait PHP en suivant une politique de nommage des fonctions beaucoup plus rigoureuse.

Cette philosophie est également la cause du refus de l'implémentation des annotations proposée récemment.

D'une part, les partisans des annotations n'ont pas su convaincre les contributeurs de la pertinence de ce qu'ils proposaient, tant au niveau fonctionnel que technique.

D'autre part, les annotations peuvent être émulée à l'aide d'outils déjà présent dans le langage, et notamment l'introspection.

Il est cependant possible d'espérer voir arriver un jour les annotations dans PHP, car Derick Rethans a posé le dossier sur la table lorsqu'il a proposé une feuille de route pour la publication de la prochaine version du langage, dont la première version alpha doit être diffusée à la fin de novembre 2010.

Il a également proposé d'intégrer APC, l'un des systèmes de cache d'opcode disponible sur le marché, dans le cœur du langage.

Cependant, aucune décision définitive n'a été prise à ce niveau, car certain problème sont à régler, le premier d'entre eux étant que pour l'instant, APC ne fonctionne pas avec la version de développement de PHP.

Et pour en revenir à l'aspect pragmatique du développement du langage, Rasmus le justifie très simplement.

Pour lui, PHP doit être un outil simple et efficace, qui doit permettre avant tout de résoudre des problèmes réels rapidement.

En conséquence, il ne faut développer que l'indispensable, et peu importe si l'implémentation sous-jacente n'est pas belle.

De son point de vue, un code mal écrit qui résout un problème vite et bien vaut mieux qu'aucune solution.

De plus, il pense qu'il est inutile de perdre du temps à développer des fonctionnalités qui ne présente pas une valeur ajoutée suffisante ou à rendre le code plus esthétique : la résolution du problème prévaut sur la beauté de la solution.

Les membres de la communauté des développeurs appliquent également cette philosophie, même si Rasmus avoue qu'ils sont certainement beaucoup moins extrémistes que lui.

Et d'après Ilia et Derick, ils l'appliquent d'autant mieux que la plupart d'entre sont des bénévoles qui développent le langage sur leur temps libre.

Ils préfèrent donc ne pas perdre leur temps à refaire plus proprement des choses qui fonctionnent alors qu'elles sont mal implémentées, et à contrario se concentrer sur des développements à forte valeur ajoutée pour le plus grand nombre plutôt que sur des choses plus exclusives fonctionnellement et nécessaires uniquement à une minorité.

Le support d'Unicode, qui devait être la fonctionnalité phare de PHP 6, fait d'ailleurs les frais de cette politique, puisque les développeurs du langage considèrent que les outils présent dans PHP actuellement pour manipuler des chaînes de caractères dans ce format sont suffisants pour répondre à la majorité des besoins.

En conséquence, depuis l'arrêt du développement de PHP 6, la communauté des contributeurs n'a fait aucun développement pour implémenter ou améliorer son support dans le langage, et il ne faut donc pas compter voir ce dernier être intégré plus fortement à PHP à court terme.

PDO, la couche d'abstraction dédiées aux bases de données, fait également les frais de cette approche pragmatique.

Il existe en effet une RFC datant de deux ans, qui pose les bases de sa réécriture complète afin de lui ajouter de nouvelles fonctionnalités.

Cependant, le développement est au point mort, notamment à cause du fait que la version actuelle est fonctionnelle et couvre un spectre suffisant des besoins des utilisateurs du langage.

Autre conséquence, la feuille de route concernant l'ajout de fonctionnalité est complètement vierge actuellement, et aussi bien Rasmus que Ilia ou Derick n'ont pu me donner la moindre indication sur une quelconque orientation.

J'ai donc lancé quelques sondes pour connaître leur ressenti par rapport à quelques technologies émergentes dans le web actuellement.

En effet, la volonté de la communauté des développeurs est de faire évoluer le langage en même temps que le web, et il m'a donc semblé pertinent de leur demander ce qu'ils pensaient d'une technologie comme node.js, par exemple, qui permet d'exécuter du code Javascript au niveau du serveur avec une gestion des entrées/sorties non bloquante.

Ilia et Derick pensent que c'est une technologie très intéressante, mais que, pour l'instant, l'intérêt d'intégrer tout ou partie des concepts sous-jacents de node.js n'est pas démontré.

Rasmus est quand à lui beaucoup plus intéressé par Gearman, qui permet faire de la distribution de tâches de manière asynchrone sur un ou plusieurs serveurs.

Il voit en effet cette technologie comme une alternative crédible aux threads, qu'il considère en conséquence comme complètement inutile au niveau de PHP.

J'ai également évoqué le départ de Lukas Kahwe Smith de la communauté des développeurs avec Ilia.

Pour mémoire, Lukas est celui qui avait une réelle volonté de structurer le développement du langage.

Pour cela, il a mis en place divers outils de suivi, ainsi que le principe des release masters et des RFC.

Le fait qu'il quitte le projet pouvait donc potentiellement avoir un impact important sur le développement du langage.

Cependant, Ilia considère que ce type d'événement est parfaitement normal dans le sens ou il fait parti du cycle de vie d'un projet libre, et qu'en conséquence, son impact est nul.

Le futur de PHP s'annonce donc intéressant, car si pour son créateur, le langage est mature et ne nécessite plus d'évolution majeure, car il lui permet de résoudre l'ensemble de ses problèmes, la porte n'est pas fermée, bien au contraire.

L'ajout de fonctionnalités ou les évolutions devront juste être en accord avec la politique de développement pragmatique appliquée par les contributeurs.

De plus, les problèmes rencontrés ces derniers mois dans le développement du langage et par sa communauté n'a pas perturbé fortement son évolution, puisqu'une nouvelle version proposant de nouvelles fonctionnalités va voir prochainement le jour, et cela même si elle n'implémentera pas Unicode ou certaines évolutions réclamées par certains utilisateurs, car jugées peu pertinentes, aussi bien fonctionnellement que techniquement.