Après un mois de janvier agité sur internals@, voici février 2013, qui n’a pas non plus été de tout repos !

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 résumer de façon très rapide les quelques points principaux :

• PHP 5.5 continue d’avancer : une version alpha5 a été publiée, et la sortie de la version beta1 a été repoussée.
• Le vote sur l’intégration de Zend Optimizer+ à PHP 5.5 a été ouvert en fin de mois.
• Plusieurs petites RFC ont été rédigées ; pas de grosse nouveauté cela dit – ce qui peut se comprendre, puisque le focus du moment est la sortie prochaine de PHP 5.5.

PHP 5.5 : Avancement

La sortie de PHP 5.5 continue de se rapprocher doucement, mais de plus en plus sûrement, avec la sortie d’une version alpha5, et de longues discussions autour du composant Zend Optimizer+ et de sa possible intégration à PHP 5.5.

PHP 5.5 : roadmap, alpha5, future beta1 ?

Je disais il y a un mois que, suite aux échanges survenus fin janvier autour de la possible intégration d’un cache d’opcodes à PHP 5.5, il se pourrait que cette version soit repoussée – autrement dit, que la beta1 ne soit pas publiée le 7 février comme initialement prévu.

Et effectivement, tout juste à la mi-février, Julien Pauli et David Soria Parra ont effectué les annonces suivantes :

• Une version alpha5 doit être publiée le 21 février, intégrant Zend Optimizer+, extension qui aura été mergée au coeur de PHP d’ici là,
• La beta1 est repoussée au 7 mars – soit un mois après la date initialement prévue,.

Les réactions ne se sont pas faites attendre : plusieurs voix se sont élevées, indiquant que le vote sur la RFC: Integrating Zend Optimizer+ into the PHP distribution n’avait pas encore eu lieu, et qu’il semblait donc “prématuré” d’annoncer dès maintenant l’intégration de cette extension (intégration qui n’a pas été votée !) ; et aussi que ce planning ne laissait que peu de temps pour tester avant le passage en phase de beta.

Heureusement, David Soria Parra a rapidement apporté quelques clarifications :

• Les deux release managers pensent que l’intégration d’un cache d’opcode est importante, et espèrent donc que la RFC va passer.
• Ils ont donc souhaité rallonger la phase de versions alpha pour permettre le merge de Zend Optimizer+ au coeur de PHP avant le passage en phase de beta,
• Mais l’intégration de Zend Optimizer+ à PHP 5.5 n’aura lieu que si la RFC est acceptée.

Le 22 février, soit une semaine après cette annonce, la version alpha5 de PHP 5.5 a été publiée.
Finalement, ZendOptimizer+ n’a pas été intégré à cette version, qui n’a apportée que quelques corrections de bugs et améliorations (autour de l’extension mysqli et de mysqlnd, notamment).

La sortie de la première version beta (qui signifie la fin de l’ajout de fonctionnalités à PHP 5.5) approchant, Pierre Joye a demandé, en toute fin de mois, à ce que les prochaines RFC, pull-requests, et suggestions d’ajout de fonctionnalités visent PHP 5.6 – et plus PHP 5.5.

PHP 5.5 et Zend Optimizer+

Comme je l’évoquais il y a quelques semaines, toute fin janvier, Zeev Suraski annonçait la RFC: Integrating Zend Optimizer+ into the PHP distribution ; l’idée étant d’open-sourcer le cache d’opcodes Zend Optimizer+ (jusqu’à présent gratuit, mais closed-source) afin de l’intégrer à PHP, même si cela pouvait signifier devoir repousser la sortie de PHP 5.5 de deux mois.

Quelques mails supplémentaires ont été échangés en février sur ce fil de discussion, sans apporter beaucoup plus d’informations, mais continuant à indiquer que le sujet intéresse du monde. Au bout de quelques jours, un tier du mois étant passé, Zeev Suraski a indiqué que le processus prenait un peu plus de temps que prévu, mais que la première version des sources devrait arriver incessamment sous peu.

Et effectivement, le lendemain, Zeev Suraski a annoncé que les sources de Zend Optimizer+ étaient disponible sur github/zend-dev/ZendOptimizerPlus/ – l’extension en elle-même étant compatible avec toutes les versions de PHP allant de 5.2 à 5.5-dev. Il en a profité pour indiquer qu’il était possible d’organiser un webinar, afin de faciliter la prise en main du code de l’extension et de son fonctionnement par d’autres développeurs (idée qui a semblé interresser du monde – ce qui ne peut être qu’une bonne chose : plus il y a de développeurs connaissant le code, mieux il sera revu et testé).

En réponse à une série de questions de Christopher Jones, Zeev Suraski a apporté quelques informations supplémentaires :

• D’après lui, le cache d’opcodes devrait être activé par défaut – si O+ est intégré à PHP, bien sûr.
• O+ est capable d’effectuer quelques optimisations – d’ailleurs, ces optimisations pouvant être coûteuses à réaliser, il semble cohérent de les coupler avec un cache d’opcodes.
• En l’état actuel des choses (et comme pour APC, d’ailleurs), il n’y a pas de caching d’opcode en CLI, puisque le processus est détruit une fois le script exécuté : la mémoire ne persiste pas “en dehors” de PHP.

Plus loin dans la discussion se sont posées quelques questions supplémentaires :

• Quel nom utiliser pour cette extension ? Y compris si elle est intégrée à PHP ? Considérant que ce nom doit être explicite, et sera aussi probablement utilisé pour une série de paramètres dans php.ini. Sur ce point, Zeev Suraski est tout à fait d’accord pour qu’un autre nom que “Zend Optimizer+” soit utilisé.
• Quelles valeurs par défaut utiliser pour ces différents paramètres ? Des valeurs plutôt “prudentes”, ou plutôt orientées “performances extrêmes” ?

D’autres échanges de mails indiquent que plusieurs développeurs ont compilé et/ou essayé l’extension :

• Pierre Joye l’a compilée pour Windows (quelques correctifs ont été apportés au passage – à peine open-source, et déjà des pull-requests ;-) ),
• Il semblerait qu’il puisse effectivement (c’était prévu) y avoir quelques soucis avec ZTS.

Après deux semaines d’échanges, les votes ont été ouverts sur la RFC: Integrating Zend Optimizer+ into the PHP distribution à la toute fin du mois.

Quelques jours après la publication des sources de Zend Optimizer+, Pierre Joye a publié les résultats de quelques benchmarks sous Windows ; il en a d’ailleurs profité pour suggérer qu’il serait intéressant de publier l’extension sur PECL rapidement, afin d’augmenter le nombre de testeurs.

Les premiers résultats semblaient remonter quelques problèmes avec Symfony (les différences pour Mediawiki pouvant – en partie ? – être expliquées par le fait qu’O+ n’intégre pas de cache de données, contrairement à APC et à Wincache : Zend Optimizer+ ne fait que du caching d’opcodes.). Un correctif a été apporté, qui semble avoir amélioré les choses.

Ces benchmarks devraient être joués régulièrement, et les résultats sont disponibles en ligne.

Pour ceux qui voudraient tester O+ sur un environnement de développement où ils auraient aussi Xdebug, notez qu’il semble falloir charger Zend Optimizer+ avant Xdebug – les choses fonctionnant moins bien si l’extension Xdebug est chargée en premier.

Ralph Schindler a fait quelques tests avec des archives Phar, et a répondu à un mail qu’il avait lui-même envoyé y a quelques mois, en notant que O+ ne semble pas souffrir de certains problèmes qu’il avait rencontré avec APC pour les stat/include avec des Phar.

Give the Language a Rest motion

Probablement suite aux nombreuses conversations de ces derniers mois à propos de modifications qui pourraient être à apporter à la syntaxe de PHP ou de nouveautés indispensables d’après certains, Derick Rethans a renvoyé un mail que Zeev Suraski avait initialement posté en mars 2006.

Déjà à ce moment là, Zeev Suraski estimait qu’il n’était pas judicieux de vouloir sans-cesse continuer à altérer la syntaxe de PHP pour ajouter de nouvelles fonctionnalités qui semblaient perçues comme indispensables par seulement un petit nombre.

Pierre Joye a rapidement profité de l’occasion pour rappeler qu’il serait bon pour les développeurs de PHP de se rapprocher des différentes communautés utilisant le langage, afin d’être plus en mesure de comprendre leurs besoins.

La réponse de Lars Strojny est intéressante : d’après lui, il bien entendu important de ne pas ajouter de fonctionnalité seulement à moitié réfléchie, mais il faut continuer à implémenter des nouveautés, pour que ce qui est faisable avec d’autres langages le soit aussi en PHP, pour permettre aux développeurs de travailler avec une syntaxe concise, ainsi que pour apporter des nouveautés les aidant, alors qu’ils ne pensaient même pas qu’ils en auraient besoin. Son mail comportait aussi un résumé un peu macro des nouveautés, en termes de syntaxe, apportées par les quelques dernières versions de PHP.

Cela dit, le point de vue de Zeev Suraski se défend aussi : comme il le souligne, ajouter de nouvelles fonctionnalités rend le langage de plus en plus complexe, et, par conséquent, moins accessible à de nouveaux développeurs (j’ajouterais qu’il est facile d’oublier ce point lorsque l’on travaille quotidiennement avec PHP depuis des annéees et que l’on suit ses évolutions au fur et à mesure de leur sortie) ; et en même temps, chaque nouvelle fonctionnalité ajoute de la complexité dans le moteur de PHP, rendant potentiellement sa maintenance plus difficile.
Je ne peux d’ailleurs que sourire lorsque je lis le passage suivant, qui fait sans aucun doute référence à Perl¹ (d’aucun diront que ça peut sonner un peu “arrogant”, mais, en même temps, c’est plutôt vrai, non ?) :

There used to be a language that was the Queen of the Web. It was full of
clever syntax. It prided itself on having a variety of expressive ways of
doing the same thing. You’re on the mailing list of the language that
dethroned it.

D’un autre côté, la notion de “retour sur investissement” est perçue différemment par chacun, et là où certaines fonctionnalités sont perçues comme inutiles par l’un, elles sont fortement attendues par d’autres – je pense par exemple aux annotations ou aux getters/setters dont j’ai parlé plusieurs fois ces derniers mois – et comme l’a souligné Pierre Joye, il est absolument nécessaire d’arriver à des compromis entre la simplicité qui était attendue dans les années 2000, et les besoins du développement “moderne”.

Rasmus Lerdorf a ensuite apporté un point de vue différent : là où le débat se focalisait jusqu’à présent sur des évolutions en termes de fonctionnalités, il ne faut pas oublier que pour certains, les nouvelles fonctionnalités et changements syntaxiques ne sont pas forcément désirés, et que des optimisations orientées performances sont beaucoup plus attendues – alors que le sujet des performances n’est que rarement abordé sur internals@, contrairement aux idées de fonctionnalités !

Et en même temps, comme l’a souligné (entre autres) Florin Razvan Patan, il serait aussi bon de se concentrer sur la fiabilité et la robustesse du langage : lorsqu’une nouvelle version apporte son lots de BC-breaks (si je puis me permettre de nuancer : il n’y en n’a pas non plus eu tant que ça avec PHP 5.4 ; et il n’y en n’a pas tant que ça de prévus pour PHP 5.5) et que des extensions critiques ne sont pas fonctionnelles avant presque un an, il ne faut pas s’étonner si elle n’est adoptée qu’extrêmement lentement – la suite de son mail est intéressante, il y évoquait différents points en rapport avec le trop faible nombre de contributeurs à PHP, et quelques idées qui pourraient aider à améliorer les choses.

Versionner le langage pour réduire les bc-breaks ?

Le mois a commencé fort, avec une discussion de plus de 45 mails lancée par Karoly Negyesi, où il suggèrait initialement que, pour faciliter la migration vers PHP 6, cette version devrait se baser sur des tags <?php incluant la version du langage, comme <?php6.

Cette idée n’est pas nouvelle, et il n’y a d’après Pierre Joye aucune chance d’y revenir ; il n’est d’ailleurs pas le seul de cet avis.

Comme Rasmus Lerdorf le souligne, il n’est pas réaliste de considérer qu’aucune cassure de compatibilité antérieure ne doit avoir lieu entre deux versions – y compris mineures – de PHP : cela signifierait que même les bugs ne doivent pas être corrigés (puisque ces corrections signifient un changement de comportement). Dans les grandes lignes, l’approche retenue pour PHP est qu’il ne doit pas y avoir de changement sur un comportement fonctionnel documenté, à moins qu’il n’y ait une raison extrêmement sérieuse (en général, liée à une problématique de sécurité) de le faire.

Un peu plus loin dans la conversation, cela dit, Karoly Negyesi a expliqué son point de vue et le pourquoi de sa proposition : on retombe sur le problème des hébergeurs (y compris mutualisés, qui représentent une part non-négligeable, au contraire, des systèmes sur lesquels sont déployés nombre de CMS) et distributions (comme la dernière Ubuntu LTS qui est encore en PHP 5.3 et ne propose toujours pas PHP 5.4) ne mettant pas PHP à jour, et continuant à proposer d’anciennes versions à leurs clients / utilisateurs.
En somme, à ses yeux, il faudrait que tout code écrit pour PHP 5.4 fonctionne sans erreur sur PHP 5.5 ; ce à quoi Rasmus Lerdorf a fort justement répondu que la première chose à faire, alors, serait de tester avec PHP 5.5 (ce serait même un bon moyen, peu coûteux en temps, de contribuer au projet PHP !), même si cette version n’est pas encore sortie en stable – et que chaque version de PHP apporte nécessairement quelques changements.

La discussion a quelque peu dévié sur les différentes versions de PHP, et sur la baisse de PHP 5.1 vs l’augmentation de PHP 5.4 vs le besoin de migrer vers PHP 5.3, ainsi que sur les méthodes de calcul, avant de revenir sur le besoin qu’expriment certains d’avoir une version “figée” de PHP 5 – et que les développements soient effectués sur une autre version réellement distincte.
Mais, en même temps, il semble normal qu’une évolution (comme un changement de version d’un composant majeur) de la plate-forme d’hébergement puisse s’accompagner de retouches au code PHP qu’elle fait tourner, non ?
Et comme l’a noté Thomas Bley, il est tout à fait possible d’utiliser plusieurs versions de PHP en parallèle sur une machine – en particulier avec FPM.

Les échanges s’éternisant quelque peu, avec d’un côté quelques participants refusant qu’une nouvelle version de PHP ne change quoi que ce soit² et de l’autre ceux qui considèrent qu’il est impossible d’éviter tout changement, plusieurs voix se sont élevées pour signifier que la marche à suivre serait de rédiger une RFC (qui n’a aucune chance de passer). Et au final, après trois jours de “discussions”, le sujet est retombé.

Divers / en vrac

Martin Keckeis a fait remarquer que la page de statistiques d’utilisation de PHP sur php.net n’était pas à jour (les derniers chiffres datent de 2007) ; Peter Cowburn a indiqué en réponse qu’il était en contact avec netcraft, et qu’il allait voir pour mettre ces statistiques plus régulièrement – presque un mois après, il n’y a pas encore eu de progrès sur ce point.

Ce n’est pas un événement en soit, mais ça m’a permis de découvrir le Jenkins d’intégration continue de PHP : Ferenc Kovacs a demandé un accès au repository git “jenkins” de PHP, pour pouvoir conserver sous gestionnaire de sources la configuration de ce dernier.

A propos de caches d’opcodes, Terry Ellison a souligné que les extensions existantes se focalisaient sur le caching dans un contexte de serveur Web servant de nombreuses requêtes, et ignoraient le cas de scripts lancés en CLI ; il en a profité pour introduire son extension LPC, qui pourrait conduire à quelque chose à ce niveau – mail qui n’a été suivi d’absolument aucun retour.

Hans-Juergen Petrich a lancé une discussion où il remarquait qu’utiliser eval() pour créer des fonctions anonymes³ entraine une fuite mémoire, si les fonctions anonymes créées le sont à partir de chaines de longueurs différentes. Après un peu de recherches à coups de debugger, Terry Ellison a noté qu’il semblait s’agir d’un bug.

Gabriel Wu a annoncé s’être mis à travailler sur l’extension operator, dont la dernière mise à jour remontait à 2006, pour, en premier lieu, la rendre compatible avec PHP 5.3 et PHP 5.4. L’échanges de mails montre un peu le processus à suivre pour devenir mainteneur d’une extension : travailler dessus, éventuellement montrer un patch ou deux (il semblerait que ça n’ait pas été le cas ici, mais il s’agit d’une extension peu utilisée, qui n’avait plus de mainteneur – ce qui facilite les choses), demander un compte pecl (pour pouvoir publier des mises à jour de l’extension) et éventuellement un compte php.net (pour héberger les sources sur le repository git correspondant, si on ne veut pas les héberger en externe), et demander aux plus expérimentés s’ils ont des conseils et retours.

Les sources de PHP sont hébergées sur un repository git, dont il existe un miroir sur github – miroir qui reçoit des pull-requests.
Là où il existait déjà l’outil Github Pull Requests pour gérer celles-ci et les merger sur le repository officiel, Johannes Schlüter a annoncé la mise en place d’un mécanisme les remontant sur le bug-tracker de PHP, en vue de faciliter le rapprochement entre un bug et une PR lui correspondant. Encore un bon point pour encourager la soumission de pull-requests, et donc la participation de nouveaux développeurs !

Il y a quelques mois, Ferenc Kovacs proposait un mail expliquant qui pouvait soumettre des RFC ; ce mois-ci, Christopher Jones a complété cette liste, en postant sur son blog : The Mysterious PHP RFC Process and How You Can Change the Web.

Asbjørn_Sannes a soumis la RFC: Add mysqlnd.localhost_override option ; après plusieurs retours plutôt négatifs, dont certains proposant d’autres solutions, la RFC est retirée.

Pour continuer avec une autre RFC, Nikita Popov a annoncé qu’il prenait la suite du travail sur la RFC: Allow non-scalar keys in foreach. Il n’y a eu que peu d’échanges sur le fil de discussion (ce qui est généralement bon signe, signifiant que tout le monde est d’accord avec l’idée – puisque personne n’a rien à dire qui s’y oppose), et le vote a été ouvert en fin de mois.

Stas Malyshev a corrigé le Bug #49348 : Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!) ; à partir de PHP 5.5, utiliser une incrémentation sur une propriété inexistante, comme $this->undefined++, lévera une E_NOTICE – c’était déjà le cas pour les variables normales.

Nikita Popov a fait remarquer que si PHP 5.4 a introduit la syntaxe (new MaClass())->maMethode(), celle-ci ne fonctionne que pour new – et pas pour d’autres instructions, comme, par exemple, clone ; pour rendre les choses plus consistentes, il a proposé d’étendre cette syntaxe à n’importe quel type d’expression.

La proposition a semblé intéresser du monde, et n’a initialement pas réellement rencontré d’opposition ; le changement proposé semblait même suffisamment peu important pour que certains suggèrent de ne pas passer par les cases “RFC” et “vote” – suggestion qui, elle, a rencontré une certaine opposition (rédiger une RFC fait parti du processus, ça permet de mettre la nouvelle fonctionnalité au clair pour tout le monde, de pointer d’éventuels cas tordus, …) : après tout, il s’agirait de modifier le comportement du parseur, et ce type de changement peut avoir un impact sur de nombreux outils gravitant autour du langage (IDE, analyseurs de code source, …).

Comme l’a par la suite souligné Dmitry Stogov, cette modification peut avoir des impacts auxquels on ne pense pas immédiatement ; ce à quoi Stas Malyshev a fait remarquer qu’il ne fallait pas sortir cette nouvelle fonctionnalité trop vite.

La conversation s’est un peu essouflée en fin de mois, sans qu’aucune décision ne soit prise. Avec un peu de chance, on peut espérer qu’elle reprenne vie dans le futur, accompagnée d’une RFC.

Nikita Nefedov a fait remarquer qu’il pourrait être intéressant de supprimer le mot-clef function lors de la déclaration de méthodes dans des classes, interfaces, et traits – après tout, ce mot-clef est quelque peu redondant et n’apporte pas de réelle information en soit.

Comme l’a rapidement souligné Johannes Schlüter, ce n’est pas la première fois que le sujet est abordé sur internals@, et, il y plus de deux ans de cela, l’idée avait été abandonnée, le mot-clef function étant pratique pour, par exemple, rechercher des définitions de méthodes à coups de grep.

Dans l’ensemble, les retours semblent plutôt négatifs, entre les greppeurs, ceux qui considèrent qu’il faudrait arrêter de vouloir changer la syntaxe de PHP “juste pour faire joli”, ceux qui privilégient la lisibilité du code, et ceux qui soulignent que ce type de modification, même si sympathique, n’est pas réellement nécessaire⁴.

Finalement, considérant le peu d’intérêt pour cette idée et la forte opposition, la conversation s’est rapidement arrêtée, sans même atteindre l’étape “RFC”.

Keyur Govande a annoncé avoir rédigé la RFC: PHP CLI changing process title support, l’idée étant d’introduire une manière permettant de renseigner le titre d’un processus PHP lancé en ligne de commande – titre qui peut être visible, par exemple, en sortie des commandes ps ou top ; ceci serait particulièrement utile dans le cas de processus durant longtemps : il deviendrait plus facile de les identifier et de les différencier.

Même si l’utilité ne semblait pas évidente à tous au premier abord, plusieurs retours ont semblé montrer un certain intérêt, y compris parmis des utilisateurs de l’extension proctitle (qui, notamment, ne fonctionne pas sous Windows, et souffre de quelques bugs génants).

Après quelques échanges de mail, Keyur Govande a annoncé vouloir ouvrir la RFC au vote ; considérant qu’une seule journée de discussion était relativement peu, finalement, les votes n’ont pas été ouverts de suite, et ne l’ont été que quelques jours après.

Les choses ont l’air plutôt bien parties ; et on peut espérer qu’à la fin de la période de votes, soit début mars, cette modification soit intégrée à PHP 5.5.

Ivan Enderlin a ouvert un sujet de discussion où il faisait remarquer que PHP ne dispose pas d’un moyen unifié permettant à un script d’être tenu au courant de modifications apportées sur des fichiers – typiquement, pour effectuer une action dès qu’un fichier dans un ensemble de répertoires donné est modifié ; ce qui est parfois utile dans un contexte de scripts PHP durant longtemps et/ou en mode démon. Il suggère qu’une fonctionnalité de ce type, fonctionnant sous Windows/Mac/Linux, pourrait éventuellement avoir sa place dans le coeur de PHP.

Julien Pauli a répondu qu’une fonctionnalité de ce type n’aurait probablement pas sa place dans le core, mais que ceux qui en ressentaient le besoin avaient la possibilité d’utiliser une extension PECL (il existe par exemple l’extension inotiy, mais pour Linux uniquement). Il n’est d’ailleurs pas le seul à avoir répondu en ce sens.

D’après Patrick Allaert, une bonne approche serait de développer ceci sous forme d’une bibliothèque C – elle même ensuite mise à disposition de PHP via encapsulation dans une extension PECL.

Sara Golemon a rédigé la RFC: Trailing comma function args. L’idée proposée est d’autoriser la présence d’une virgule à la fin de la liste d’arguments lors d’un appel de fonction (de manière à ce que ma_fonction('plop', 'glop', ); soit syntaxiquement valide), de la même manière que c’est depuis toujours autorisé pour les déclarations de tableaux (comme $a = array('plop', 'glop', ); ).

Dans l’ensemble, l’idée a semblé être appréciée, notamment parce qu’elle implémenterait une syntaxe cohérente avec celle permise pour les tableaux, sans changer le comportement existant (si ce n’est autoriser une syntaxe qui ne l’était jusqu’à présent pas).

Cela dit, les retours n’ont pas tous été positifs ; comme l’a remarqué Alain Williams, autant il est fréquent d’ajouter un élément en fin de liste, autant il est plus rare d’effectuer ce type de modification sur un appel de fonction/méthode.

Dans la foulée, Marcello Duarte a annoncé avoir rédigé la RFC: Short syntax for anonymous functions. Dans l’ensemble, les retours semblent avoir été un peu plus négatifs sur celle-là, que ce soit parce que la syntaxe proposée ne plait pas, parce qu’elle introduit un risque de BC-break, ou parce que l’idée en elle-même ne semble pas nécessaire – sans compter le risque de nuire à la lisibilité du code. Cela dit, même sans forcément apprécier la syntaxe, d’autres ont visiblement apprécié la proposition, allant jusqu’à essayer de l’améliorer.

Paul Reinheimer a rédigé un mail à propos d’un sujet qui est revenu dans plusieurs discussions ces derniers mois : la majorité des développeurs utilisant PHP ne va pas à des conférences, ne lit pas internals@, et est finalement assez silencieuse. En conséquence, les développeurs de PHP peuvent parfois être quelque peu déconnectés de la réalité des utilisateurs du langage.

Une possibilité pour en savoir plus sur les besoins des différents types de développeurs travaillant avec PHP pourrait être de mettre en place un sondage – qui devrait être suffisamment réfléchi et construit de manière suffisamment scientifique pour qu’il soit possible d’en tirer des enseignements utiles.

Cela dit, Christopher Jones a fait remarquer que les choses pourraient / devraient aussi aller dans le sens inverse : pour lui, il faudrait que plus de membres de la communauté deviennent développeurs de PHP, et non plus “seulement” utilisateurs. Malheureusement, comme l’a rapidement noté Kris Craig, la plupart des développeurs utilisant PHP ne seraient pas forcément à l’aise avec du C.

Pour essayer de faire avancer les choses, Florin Razvan Patan a commencé à rédiger la RFC: Site voting poll. A voir comment cela évoluera sur les prochaines semaines ?

Et pour finir avec un peu d’humour, Aaron Holmes a fait remarquer que le XKCD 1172⁵ faisait beaucoup penser à ce qu’il se passe parfois avec PHP :

Crédits : XKCD #1172

En même temps, ce n’est pas loin de la vérité non plus…

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.

Je simplifie peut-être un peu, au risque d'être caricatural -- vous devinerez aisément de quel côté je me positionne ^^

Bon, aussi, utiliser `eval()` pour créer des fonctions anonymes...

Forcément, en cours de route, la conversation a un peu déviée sur le nombre de développeurs qui utiliseraient `grep` pour rechercher des fonctions, ceux qui travaillent avec un IDE, ceux qui ne savent même pas ce qu'est `grep`, ou encore ceux qui considèrent que Linux est un IDE...

J'ai fait un peu de Perl dans mon "jeune temps" ; c'était fun comme langage... et il y avait moyen de s'amuser avec sa syntaxe ^^ Par contre, sur des projets de la taille de ceux sur lesquels j'ai bossé ces dernières années... je craindrais ^^

Oui, je fais parti de ceux qui apprécient XKCD et ont tendance à y faire référence ici et là ;-)