134 posts taggués « php »

Par Pascal MARTIN le lundi 8 septembre 2014 2 commentaires

Le 30 juin 2009 sortait PHP 5.3.0.

Après des années d’efforts et alors que PHP 6 ne semblait pas réellement se rapprocher, PHP 5.3 a apporté un lot de nouveautés importantes. Pour n’en citer que quelques-unes qui m’ont le plus marquées1 :

  • Le support des espaces de noms,
  • Les fonctions anonymes et les closures.
  • Plusieurs classes de l’extension intl visant à faciliter l’internationalisation et la localisation d’applications.


Ces évolutions — et surtout les deux premières — ont posé les fondations utilisées ensuite pour revitaliser le développement en PHP : je pense en particulier aux travaux effectués par la communauté au niveau de l’auto-loading (notamment via la PSR-0), la mise en place et l’acceptation de composer, ainsi que le lancement de frameworks de seconde génération.

Pour moi qui ai commencé à travailler avec PHP dans un contexte pro sous PHP 5.1 et qui ai suivi — avec plus ou moins de retard en fonction des projets — les montées de versions successives vers PHP 5.2, puis 5.3 et maintenant 5.5 et bientôt 5.6, cette version 5.3 a marqué un tournant au niveau du langage et de sa communauté : d’un langage souvent perçu comme utilisé par des bidouilleurs, nous sommes passés à un langage et à des solutions résolument orientés professionnels.

Au niveau de l’évolution du langage en lui-même, PHP 5.3 a aussi ré-amorcé la pompe : avec l’admission que PHP 6 n’était pas encore prêt, PHP a recommencé à évoluer — et cela s’est vu à travers les versions qui ont suivi, avec PHP 5.4 en 2012, PHP 5.5 en 2013 et PHP 5.6 cette année.


Mais aujourd’hui, après tant d’années de bons et loyaux services, il est temps de dire adieux à PHP 5.3.

En effet, comme annoncé lors de la sortie de PHP 5.4, PHP 5.3 a atteint sa fin de vie2cet été : plus aucune correction ne sera apportée à PHP 5.3, que ce soit pour des bugs (y compris majeurs) ou même des failles de sécurité.

Si vous ne l’avez pas encore fait, il est donc plus que temps de songer à migrer vers une version plus récente — la raison voudrait que vous passiez à PHP 5.5 dès maintenant, en commençant dans la foulée à étudier la migration vers PHP 5.6 qui vient de sortir. J’ai moi-même réalisé la migration 5.3 → 5.5 cette année3 sur plusieurs applications et j’ai été agréablement surpris de voir à quel point elle a été sans douleur4 !


Et pour conclure, j’adresse un grand “Merci !” à tous ceux qui ont fait de PHP 5.3 la version mineure majeure qu’elle a été : contributeurs, Release Managers, testeurs, évangélisateurs, utilisateurs, …



  1. Je parlerais bien de goto, mais vu que je n’en n’ai toujours pas utilisé (ni vu utilisé) en toutes ces années, je ne peux dire que ça m’ait vraiment marqué ^^ 

  2. “Fin de vie”, ou “EOL” pour “End Of Life”

  3. J’ai d’ailleurs donné une conférence intitulée « PHP 5.3 → 5.6 : No pain but gain ! » au PHPTour 2014 à Lyon. Les slides sont disponibles, de même que la vidéo

  4. Bien sûr, si vous tournez encore sur une version encore plus ancienne — comme PHP 5.2 —, les choses pourraient être un peu plus complexes… Mais est-il utile de vous rappeler que PHP 5.2 a atteint son EOL il y a encore plus longtemps ? 

Par Pascal MARTIN le mardi 22 juillet 2014 1 commentaire

J’ai posté il y a quelques jours les notes que j’ai prises lors des conférences auxquelles j’ai assisté le premier jour du PHPTour 2014 à Lyon.

En plus d’avoir pu échanger avec plein de monde et assister à une quinzaine de présentations, j’ai aussi cette année eu la chance de participer à deux conférences — toutes deux basées sur le travail que j’effectue chez TEA, The Ebook Alternative :

  • « Notre environnement de développement n’est plus un bizutage ! » avec Julien Fusco le premier jour,
  • et « PHP 5.3 → PHP 5.6 : no pain but gain ! » le second.

Dans la suite du premier post publié la semaine dernière, voici, encore dans l’ordre chronologique, mes notes du second jour. Notez qu’il s’agit de mes notes, soumises à mon interprétation de chaque intervention.

Les slides de la quasi-totalité des conférences sont disponibles sur joind.in et les vidéos captées lors de l’événement vont peu à peu être diffusées par l’AFUP sur youtube.


Déploiement continu : Click and deploy !

Sophie BeaupuisRésumé, Slides

Après l’apéro communautaire de la veille, Sophie a eu la difficile mission d’animer une des premières conférences de la seconde journée de ce PHPTour. Elle a commencé par rappeler que le but de Zend est de rendre PHP professionnel et accessible aux entreprises — le sujet de sa conférence s’inscrivant dans cette logique.

Le constat initial est que les développeurs ont tendance à perdre du temps : correction de bugs, mise en place d’environnement, écriture de tests qui ne sont pas utilisés (lancés quand on est les écrit et quasiment plus jamais ensuite). Du point de vue des DSI, l’innovation est freinée par la lenteur technique, les pannes répétées impactent le CA, et les mises en production sont compliquées et échouent trop souvent.

Principes pour améliorer tout ça :

  • Automatiser : pas besoin d’un développeur pour faire quelque chose qu’une machine sait faire,
  • Répéter ⇒ meilleure maîtrise + détection des problèmes au plus tôt,
  • Monitorer : la collecte d’informations permet d’améliorer la qualité.

La seconde partie de la présentation était orientée autour d’une démonstration montrant comment déployer en production après chaque commit git — à travers un processus d’intégration continue sous Jenkins chargé de jouer les tests, de créer un package de déploiement, et de déployer celui-ci (cette dernière étape n’étant pour l’instant lancée qu’après validation par un humain).

Sous Jenkins, plusieurs jobs, qui correspondent chacun à des tâches Phing :

  • Un job qui extrait les sources depuis git,
  • Un job pour créer une archive de déploiement (archive qui pourrait alors être déployée sur un ou plusieurs environnement(s), sur un ou plusieurs serveur(s)),
  • Un job pour les tests en analyse statique,
  • Et un job pour le déploiement en lui-même.

Pour résumer : en principe, tout peut — et doit — être automatisé !

Mon avis : Maîtriser ses déploiements (et ne les effectuer que si les tests passent) me semble indispensable, mais plusieurs discussions que j’ai eu après cette conférence montrent que trop de développeurs n’ont pas encore industrialisé cela. Un rappel utile, donc.


Stop Multiplying by 4: Practical software estimation

Reeves CharlesRésumé, Slides

Charles a introduit sa présentation en indiquant qu’il travaille en freelance — et qu’il doit donc facturer ses clients.

Estimer permet de mesurer l’effort à fournir (et pas uniquement de calculer des deadlines) et les estimations devraient être réalisées par les développeurs, qui sont les propriétaires du code et savent quel effort un développement va nécessiter : les PO et CP ne devraient pas estimer, puisque leurs avis vont être biaisés (par exemple : ils connaissent le budget et vont faire en sorte que ça rentre dedans).

Les développeurs peuvent résoudre des problèmes complexes… Mais estimer est parfois à la limite de l’impossible !

Pour parvenir à estimer, il est indispensable d’avoir des requirements : des spécifications précises peuvent permettre de constituer un élément mesurable. Cette notion de précision dans les spécifications est indispensable. Par exemple, s’il est écrit qu’une donnée doit être “validée”, il est indispensable de savoir en quoi consiste cette validation (valider un format ? valider une donnée en appelant un web-service distant ? valider une adresse mail en envoyant un mail contenant un lien prouvant que le mail a été reçu ?).

Quelques autres exemples de modificateurs qui entraînent des spécifications vagues :

  • rapide, efficace ⇒ à reformuler en, par exemple, “5 secondes”
  • valide, etc, incluant mais pas limité à …
  • maximiser, minimiser, optimiser, au moins
  • simple, facile, user-friendly

Il est possible d’utiliser quelques méthodes pour s’aider lors des estimations :

  • Utilisation de données historiques
    • On sait combien de temps quelque chose prend en général ⇒ on réutilise ce temps
    • La vélocité peut aussi donner une idée
  • Partir sur un prototype ou sur les tests unitaires, pour avoir une idée du travail à effectuer
  • Estimer par un intervalle “entre X et Y” : il vaut mieux être à peu près juste que précisément faux
  • Répéter : ré-estimer le lendemain pour vérifier si on est d’accord avec l’estimation de la veille
  • Test absurde : on commence par des estimations “de folie” et on réduit de plus en plus précisément
  • Méthode Wideband Delphi : 3 chiffres successifs avec discussions entre pour affiner

Pour finir : il faut enlever les gens du problème, penser à l’intérêt des fonctionnalités (et pas rester sur les positions de chacun : on vise à arriver au minimum requis et, ensuite seulement, faire la suite). Ne pas négocier les estimations : les développeurs sont ceux qui savent combien de temps ça prend effectivement et ce qui est le mieux pour le code. Ajouter des développeurs ne résout pas forcément le problème. Et il faut itérer et être honnêtes.

Mon avis : Une passe intéressante sur plusieurs approches possibles pour affiner des estimations et arriver à des chiffres réalistes. L’idée que seuls les développeurs doivent chiffrer (et pas le chef de projet ni le product owner) est intéressante : après tout, c’est nous qui construisons l’application et sommes souvent les mieux placés pour déterminer combien de temps il nous faudra.


Everything you always wanted to know about UTF-8 (but never dared to ask)

Juliette Reinders FolmerRésumé, Slides

Pour introduire sa présentation, Juliette a demandé qui avait déjà utilisé UTF-8 et qui avait déjà eu des problèmes avec. Forcément, tout le monde a levé la main. Mais Unicode ≠ UTF-8 ≠ Internationalisation. Pourquoi penser UTF-8 ? Parce que rien n’est local. Même au sein d’une entreprise, on peut avoir des filiales à l’étranger, des fusions, des noms d’employés étrangers, … Et gérer tout ça, c’est plus facile si c’est fait dès le début !

Il existe plus de 7000 langues vivantes, dont plus de 300 parlées par plus d’un million de personnes (et la Nouvelle Guinée compte à elle seule 837 langues différentes). Parmi les 20 langues les plus utilisées, seulement 7 sont en script latin. Plus de 180 scripts d’écriture sont actuellement utilisés (certains sont utilisés pour plusieurs langues ; certaines langues ont plusieurs systèmes d’écriture ; et certains sont utilisés pour la religion, les cérémonies, ou purement pour le fun (Klingon par exemple)).

Character Set = groupe de caractères → code page → code point. Encoding = part du code page et donne le binaire qui stocke le caractère. Unicode (charset) couvre tout, et peut être représenté par plusieurs encodings (UTF-8, 16, 32).

UTF-8 est le plus simple des encodings Unicode :

  • compatible ASCII
  • taille de caractères variable
  • peut encoder tous les caractères Unicode
  • Défaut pour XML et standard pour HTML
  • peut être reconnu assez facilement, faible risque de confusion
  • tri par tableau d’unsigned ⇒ même ordre que le code point Unicode

Le problème est que tout le monde utilise autre chose par défaut et qu’il faut donc être explicite partout !

  • Ordinateur de l’utilisateur : peu de fontes sont capables de gérer plein de trucs Unicode : il faut travailler avec des fontes compatibles Unicode et ne pas réutiliser les codes ASCII pour d’autres caractères !
  • HTML : il faut déclarer l’encodage : en-têtes HTTP et tout en haut du document HTML (utile si l’utilisateur enregistre la page, par exemple — et n’a donc plus les en-têtes HTTP)
  • CSS : encoding sur la première ligne du fichier, utiliser des fontes compatibles Unicode (avec catch-all sur serif / sans-serif à la fin)
  • FTP : transférer les fichiers en binaire !
  • Réception de données depuis le client : utiliser accept-charset="UTF-8" pour les formulaires

Au niveau de PHP, les choses se sont un peu améliorées en PHP 5.3 (arrivée de l’extension Intl) ; et sont de mieux en mieux à chaque version (intl gagne en fonctionnalités). Toutefois, peu de fonctions de base sont en Unicode. Attention aux fonctions qui impactent le processus entier, comme setlocale() ou gettext().

Pour ce qui est de la base de données MySQL, travailler avec des versions raisonnablement récentes (>= 4.1), utiliser set names pour paramétrer l’encodage au niveau de la connexion, tout mettre en UTF-8 au niveau de la configuration du serveur.

Mon avis : Plusieurs rappels utiles ; j’ai bien accroché sur la partie sur les fontes (avec exemples en images sur les slides, illustrant différents types de problèmes), qui est assez éloignée de ce sur quoi je me concentre habituellement. Dommage que la présentation ait été trop longue pour tenir sur la durée allouée et que la fin ait donc été coupée.


L’asynchrone en PHP, c’est possible !

Olivier DolbeauRésumé, Slides

Pour introduire cette conférence, Olivier est parti d’un exemple assez classique : une fonctionnalité “mot de passe oublié” qui envoie un mail à l’utilisateur. Envoyer un e-mail est long et il est dommage de bloquer un processus serveur Web pour effectuer cette manipulation. A la place, il est plus intéressant d’immédiatement afficher un message à l’utilisateur indiquant que le mail est parti, tout en envoyant le mail un peu plus tard, en arrière-plan.

Le principe alors utilisé serait le suivant :

Serveur Web -> Broker --> worker (consumer)
               (AMQP) \-> worker (consumer)
                       \> worker (consumer)

Le broker est chargé de recevoir des messages et de les distribuer aux workers capables de les gérer. Olivier travaille avec RabbitMQ, mais le principe est sensiblement le même pour les différentes alternatives. Au niveau de PHP, l’extension php_amqp est utilisée.

Les workers sont des processus qui doivent tourner en permanence. Il faut donc éviter les Fatal Errors et/ou Exceptions non catchées (par contre, au développeur de logguer ce qui doit l’être, bien sûr). Pour éviter d’éventuels problèmes de fuites mémoire, les workers sont fréquemment redémarrés (après plusieurs minutes ou X messages traités) ; même chose lorsqu’il faut les mettre à jour : ils sont proprement coupés avant d’être mis à jour puis redémarrés.

Sur un projet symfony, il n’est pas forcément utile / recommandé de charger tout le framework pour un worker : chaque worker doit faire son job et rien de plus, ne serait-ce que pour limiter la consommation mémoire.

Quelques points supplémentaires :

  • Utilisation de supervisord pour construire des pools de workers
  • Attention aux outils / bibliothèques qui conservent plein de données en mémoire (comme le logguer finger crossed de Monolog qui, par défaut, garde tous les logs en mémoire)
  • En cas d’échec d’un worker lors du traitement d’un message, ré-essayer plus tard (30 secondes, puis 3 minutes, … de plus en plus longtemps)

Mon avis : J’étais déjà convaincu que sortir des traitements du serveur web pour les effectuer en arrière-plan était une approche viable en PHP (je le fais depuis des années en me basant généralement sur gearman, avec des pools de workers gérés par supervisord). Il était intéressant de voir une solution basée sur une autre brique technique, ainsi que sa mise en pratique sur des applications à forte charge, qui montre ouvertement que c’est possible.


PHP 5.3 → PHP 5.6 : no pain but gain !

Pascal MARTINRésumé, Slides

Pour cette seconde conférence que je donnais au PHPTour, j’ai commencé par rappeler les principales nouveautés qu’avaient apportés PHP 5.3, 5.4 et 5.5 — pour en arriver au fait que PHP 5.3 représente un peu plus de la moitié des installations de PHP 5, alors que PHP 5.5 n’en n’est qu’à environ 2%. D’ailleurs, PHP 5.3 est la version de PHP la plus utilisée actuellement, alors qu’elle va atteindre sa fin de vie cet été ! J’ai aussi passé rapidement en revue quelques-unes de nouveautés de PHP 5.6 (La conférence de Rasmus en ouverture des deux jours du PHPTour entrant plus en détails, avec exemples de code à l’appui, je suis passé rapidement sur cette partie).

En seconde partie, je suis entré dans le vif du sujet, en dressant un tour d’horizon des problèmes potentiels que l’on pouvait rencontrer pendant une montée de version de PHP. J’ai enchaîné avec plusieurs approches que l’on peut utiliser pour faciliter celle-ci, en insistant sur la mise en place d’analyse statique de code (avec PHPCompatibility, qui est un standard pour PHP_CodeSniffer).

Enfin, j’ai donné quelques conseils, basés sur les migrations successives que j’ai eu l’occasion de réaliser ces dernières années — nous sommes d’ailleurs, chez TEA, The Ebook Alternative, en train de finaliser une migration PHP 5.3 → 5.5 et pensons enchaîner sur PHP 5.5 → 5.6 en seconde moitié d’année.

Comme pour la conférence donnée avec Julien Fusco en fin du premier jour, je n’ai pas pris de note pendant la présentation (j’étais un peu occupé ;-) ), mais je vous encourage vivement à parcourir mes slides, en pensant à consulter les notes du présentateur : avant de diffuser ceux-ci, j’ai veillé à rendre ces notes aussi complètes que possibles, afin que les slides apportent un maximum d’informations à ceux qui n’auraient pas pu assister à la présentation.

Mon avis : Je me suis plusieurs fois plongé dans le sujet ces dernières années et il me tient tout particulièrement à cœur (ne serait-ce que parce que je souhaite pouvoir travailler avec les fonctionnalités des versions récentes de PHP — pour moi qui suis régulièrement l’évolution du langage, rester coincé sur une vieille version est parfois quelque peu frustrant ^^ ). J’ai donc beaucoup apprécié pouvoir donner cette seconde présentation lors de ce PHPTour.


Prévenez la dette technique de vos projets

Bastien JaillotRésumé, Slides

Pour cette dernière conférence de la journée, Bastien a commencé par rappeler que la dette technique est un emprunt réalisé sur la qualité en vue d’avancer plus rapidement, tout en sachant qu’on sera par la suite pénalisé. La dette technique est inévitable et n’est pas forcément une mauvaise chose, puisqu’elle permet de sortir des produits plus rapidement, en faisant passer les besoins fonctionnels avant les besoins techniques — il s’agit alors d’un problème plus humain que technique.

Il existe quatre types différents de dette technique :

  • celle causée par un développeur qui découvre une techno,
  • la dette SSII, que l’on trouve quand les développeurs sont payés au nombre de tickets traités,
  • la prise de raccourcis qu’on paiera plus tard,
  • et celle qu’entraîne un développeur qui n’a plus envie de toucher à une vieille techno, au bout de quelques années.

La dette technique a un impact majeur : pour un développeur, elle n’est pas vraiment attirante. Et là où un développeur peut quitter le projet, pour l’entreprise, ce n’est pas bon sur le long terme. En complément, on développe trop de choses : il faut savoir dire “non” et se concentrer sur l’essentiel (après tout, le meilleur code, c’est celui qui n’a pas besoin d’être écrit !).

Au niveau de la prise de décision, les gens ne se comprennent pas vraiment ⇒ on ajoute des intermédiaires et des dépendances à des gens “qui ne veulent pas”. On finit par penser plus à nos intérêts qu’à autre chose. Pour aider, la culture d’entreprise joue : elle pousse à vouloir faire bien (en échange, on fait des trucs fun). Il est important d’expliquer les contraintes et de comprendre les enjeux fonctionnels, sans hésiter à montrer la dette technique.

Pour ce qui est de la gestion du temps, penser qu’on ne peut pas avoir rapide + pas cher + bonne qualité. Le projet peut avancer, mais qu’en est-il de la dette technique et de la frustration des développeurs ? Prévoir la mise en production bien avant la fin de la collaboration et/ou du contrat, effectuer une release le plus tôt possible et les features suivantes arriveront après (et peut-être qu’on réalisera qu’elles n’étaient en fait pas utiles !).

En contre-partie, ne pas oublier que le beau code n’est pas utile s’il ne répond pas à un besoin, que le développeur est un créatif qui a son ego, et que la (sur-)qualité peut aussi être une source importante de dette technique (est-il vraiment utile de mettre en place plein d’outils… pour générer une page statique ?). Une ré-écriture de 0, même si l’idée est plaisante (le 1er jour) est quelque chose de dangereux, aussi !

Pour conclure : l’ennemi de la dette technique, c’est le pragmatisme. A nous de faire le maximum pour qu’on ne nous impose pas de rajouter trop de dette !

Mon avis : Une passe sympathique sur plusieurs causes de dette technique, ainsi qu’un rappel indispensable sur le fait qu’elle est parfois utile, mais aussi que c’est notre boulot de savoir la gérer (à la fois en l’acceptant lorsque c’est judicieux, mais aussi en sachant la rembourser lorsqu’on en a l’occasion).


Lightning talks

Cette seconde journée du PHPTour s’est terminée par 6 lightning talks :


En keynote de cloture, Mikaël Randy et Maxime Teneur ont indiqué que le Forum PHP aurait lieu les 23 et 24 octobre 2014 à Paris — le CFP est d’ailleurs ouvert !

Pour ma part, je suis reparti de ces deux jours épuisé (deux jours à me coucher tard après le diner des conférenciers et l’apéro communautaire, deux conférences préparées et présentées, deux journées sans faire de pause) et en pleine forme (plein de gens rencontrés, beaucoup d’échanges avec les autres conférenciers et avec le public, de nombreuses conférences intéressantes, et plein de bonnes idées en tête !). Vivement la prochaine fois !

Et pour finir, puisque c’est sans aucun doute eux qui ont fait le plus dur : merci à toute l’équipe d’orga qui a fait un super boulot !


Par Pascal MARTIN le mercredi 16 juillet 2014 2 commentaires

Le PHPTour organisé par l’AFUP a cette année eu lieu les 23 et 24 juin, à la Manufacture des Tabacs à Lyon.

Ces deux jours ont été pour moi l’occasion de revoir plein de monde, de mettre des têtes sur des noms et de rencontrer plusieurs personnes avec qui j’échangeais depuis des années sans jamais les avoir vues, ainsi que d’assister à une quinzaine de conférences.

J’ai aussi, cette année, eu l’occasion de participer à deux conférences — toutes deux basées sur le travail que j’effectue chez TEA, The Ebook Alternative :

  • « Notre environnement de développement n’est plus un bizutage ! » le premier jour,
  • et « PHP 5.3 → PHP 5.6 : no pain but gain ! » le second.

J’ai tenté de prendre quelques notes lors de chaque conférence à laquelle j’ai assisté. Voici donc ci-dessous, dans l’ordre chronologique, celles du premier jour. Notez qu’il s’agit de mes notes, soumises à mon interprétation de chaque conférence.

Les slides de la quasi-totalité des conférences sont disponibles sur joind.in et les vidéos captées lors de l’événement vont peu à peu être diffusées par l’AFUP sur youtube.


Coding and Dreaming - PHP in 2014

Rasmus LerdorfRésumé, Slides, Vidéo

Les deux jours de conférences se sont ouverts sur une présentation de Rasmus Lerdorf, qui a commencé par un historique de PHP, avant d’enchainer sur les nouveautés de PHP 5.5 et 5.6, pour conclure sur le fait que ce qui compte dans nos métiers, ce n’est pas tant les applications que nous développons, mais plutôt ce qu’elles apportent.

Au départ, pour développer pour le Web, on écrivait des CGI en C, puis en Perl. Dès 1994, Rasmus aurait voulu quelque chose de plus sympa à utiliser — et PHP a commencé comme ça (avec de la syntaxe alternative pour les structures de contrôles, d’ailleurs). Avoir une syntaxe “HTML + balises” était une bonne approche, puisque ceux qui faisaient du web étaient plus souvent des documentalistes que des développeurs.

En 1996, PHP permettait déjà plein de choses. Et dès 1997, Rasmus a reconnu que PHP était trop large pour un seul mainteneur — il a donc dit à ceux qui ralaient à propos de bugs qu’ils pouvaient se débrouiller pour les corriger (même si ça n’a pas été facile pour lui, qui n’aurait des fois “pas codé ça comme ça”).

Pour qu’un langage fonctionne, c’est son écosystème qui compte : Perl et mod_perl n’étaient pas adapté à de l’hébergement mutualisé et ne satisfaisait donc pas les hébergeurs. PHP, par contre, chargé uniquement du contenu, était plus adapté, avec des gestions de timeouts, de limite mémoire, … La stack LAMP et le mod_php d’Apache, qui évite de forker à chaque requête, a fortement aidé à répondre au “problème du web”.

Des points que l’on considère pour certains comme horribles aujourd’hui ont aussi aidé PHP à démarrer et à se démocratiser :

  • register_globals, par exemple, rendait plus facile l’apprentissage du langage par les débutants,
  • la syntaxe à base de $var pour les variables était plus facile à parser,
  • les magic_quotes étaient pratiques pour la base de données utilisée par Rasmus,
  • et les inconsistances d’API s’expliquent par le fait que PHP est souvent un simple wrapper autour d’une bibliothèque C, en mappant 1-1 les paramètres.

La présentation a continué avec les principales nouveautés apportées l’an dernier par PHP 5.5 et celles qu’apportera bientôt PHP 5.6 — je ne les passe pas en revue ici. Par contre, PHP 5.5 est aujourd’hui la version minimale que nous devrions utiliser !

En dernière partie, Rasmus a expliqué que “Coding”, finalement, n’est pas si important, et qu’il faut un juste milieu avec “Dreaming” : ce qui compte, quand le monde change, c’est lorsque les hackers s’y mettent et que l’on combine des idées avec leur réalisation.

Il a rappelé qu’il venait d’un endroit où tout le monde se fout d’Internet et que ce que l’on fait ne compte pas pour la majorité du monde : nos applications pourraient disparaitre, ça ne serait pas grave. Ce qui compte, c’est de fournir plus de valeur que nous n’en extrayons.

Mon avis : J’avais déjà vu cette conférence (j’avais regardé la vidéo enregistrée à Mexico, où Rasmus avait donné une version plus longue de cette présentation), mais il est malgré tout toujours agréable d’entendre parler de l’histoire de PHP (ça aide à remettre des choses en perspective), et encore plus de la bouche de son créateur.


Extract Till You Drop

Mathias VerraesRésumé, Slides, Vidéo

Pour cette conférence, Mathias a réalisé une session de live-coding où il est parti d’un bout de code un peu legacy pour le modifier à travers plusieurs itérations visant à le rendre plus lisible, plus clair, moins couplé et plus maintenable.

En regardant la portion initiale de code, on pouvait notamment remarquer :

  • des variables peu claires et mal nommées,
  • des conditions imbriquées,
  • des exceptions correspondant à des règles métier,
  • ou encore, des méthodes dont le nom ne reflétait pas le comportement.

Les différentes étapes du refactoring ont globalement été les suivantes :

  • ajout de tests de non-régression avec mocks sur les interfaces,
  • coups d’oeil réguliers au code-coverage (pas dans le sens “métrique de vanité”, mais pour avoir une idée de ce qui est testé et pour vérifier que l’on test ce que l’on pensait qu’on testerait),
  • dés-imbrication des conditions pour diminuer le nombre de niveaux d’indentation,
  • suppression de variables temporaires en in-linant des appels de méthodes,
  • sortie de tests de validité et de levées d’exceptions vers des sous méthodes du genre guardAgainstDuplicate(),
  • déplacement de vérifications directement vers la couche métier (ainsi, accéder directement aux objets métier sans passer par la couche service ne permet plus de sauter de validation)

Au final, il en est ressorti :

  • une méthode principale beaucoup plus courte,
  • des tests correspondant aux règles métier,
  • et du code nettement plus lisible !

Mon avis : une passe sur des principes que l’on commence à connaître, mais que l’on prend trop rarement le temps de mettre en pratique à fond. J’ai réalisé pendant la session de live-coding que j’avais encore pas mal de raccourcis-clavier de PhpStorm à maîtriser ^^


PHP, au cœur de la stratégie Open Source de Microsoft ?

Pierre Joye, Benjamin Moulès, Frederic Aatz — Résumé, Vidéo

En première partie de cette conférence, Frederic a expliqué que l’organisation au sein de Microsoft changeait au niveau de toute la boite et que l’entreprise avait des personnes dans tous les pays pour expliquer ce que fait Microsoft et établir des ponts et passerelles. Le sponsoring du PHPTour à Lyon ou le partenariat avec SensioLabs autour de symfony et d’Azure s’inscrivent dans cette démarche.

Après cela, Pierre a présenté quelques statistiques en rapport avec PHP et a rappelé quel est le cycle de releases suivi par PHP ces dernières années. Le mécanisme d’évolution de PHP a été amélioré ces dernières années (via les RFC, les votes qui sont fait dessus, et une certaine diminution des batailles sur internals@), même s’il est encore parfois difficile de contribuer à cette communauté qui ne semble pas toujours assez ouverte.

PHP a accueilli ces derniers temps bon nombre de nouveaux contributeurs et Pierre souhaiterait voir dans le top 10 uniquement des “nouveaux”. Ajoutons que “participer à PHP” ne veut pas nécessairement dire “coder en C” : le projet a besoin de volontaires pour maintenir la documentation, écrire des tests, … En somme : contribuez !

Microsoft participe activement au développement de projets open-source, dont le noyau Linux, nodejs, samba, Vagrant ou Docker. Pour PHP, en plus de développeurs participant au projet, une plate-forme d’intégration sur des tests autour de PHP a été mise en place (sur une cinquantaine de grosses applications, une fois par jour, en modes NTS et TS).

Enfin, Benjamin et Stéphane ont parlé de déploiement de symfony sur la plate-forme Azure de Microsoft, notamment facilitée par un bundle permettant de travailler directement en ligne de commandes, ainsi que par le biais des fichiers .user.ini ajoutés à PHP >= 5.3.

Mon avis : Microsoft s’ouvre à PHP et aux logiciels libres, de plus en plus depuis quelques années, et c’est une très bonne chose pour la communauté — qui essaye elle-aussi d’avancer petit à petit, en structurant ses processus et se rendant plus accessible.


Comment grapher et visualiser vos data ?

Grégoire PineauRésumé, Slides, Vidéo

Pour la conférence suivante, Grégoire nous a parlé de Graphite et des outils qui vont autour.

Pourquoi grapher les données ? Par exemple, pour voir si une fonctionnalité est utilisée, ou pour voir si une page est lente alors qu’elle est appelée fréquemment.

Quoi grapher ? Les comportements utilisateurs (pages les plus vues, temps de chargements, … ), santé de l’infrastructure (charge, espace disque, … ), mais aussi et surtout : données métier. En fait, tout pourrait être graphé.

Quand on dit “Graphite”, on pense fréquemment à une pile composée de plusieurs éléments :

  • Application (PHP par exemple) qui envoi des données à Carbon
  • Carbon : démon (protocole texte) qui reçoit les données
  • Whisper : base de données stockant celles-ci via des fichiers de taille constante (+ rapide) avec agrégation des anciennes valeurs
  • Graphite : exploitation des time-series via un affichage de graphes brut ou au travers de fonctions (moyenne, différences, … )

Carbon ne garde, sur un intervalle, que la dernière donnée reçue. On positionne donc devant un démon statsd (en node.js, qui écoute en UDP — donc sans blocage, quitte à perdre quelques paquets) chargé de regrouper les données reçues sur cet intervalle pour n’avoir en sortie qu’une seule valeur. Attention à la configuration : les fenêtres de sampling doivent être identiques du côté de statsd et du côté de Carbon, et l’agrégation par défaut de Carbon (moyenne) n’est pas toujours la bonne et est donc parfois à configurer.

La pile devient donc : Application → statsd → Carbon → Whisper → Graphite

Pour les applications en PHP, il existe 36 bibliothèques, dont celle développée par m6web ou celle de berbelei. Pour symfony, il existe un MetricsBundle qui permet de se brancher sur plein de listeners.

Quelques astuces et points à retenir :

  • Nommage : on peut utiliser des * dans les noms des métriques. Pour les compteurs, utiliser des verbes au passé, comme machin.created
  • Graphite fait beaucoup d’I/O ; il est recommandé de l’installer sur un SSD
  • La configuration est écrite à la création des fichiers et ne peut plus être modifiée par la suite

Pour la visualisation des données, le moteur Graphite est directement utilisable mais moche. Il existe plein de moteurs de dashboard, comme Grafana (basé sur Kibana, tout en HTML/JS/CSS, avec auto-refresh, time-range, query-builder, …).

Mon avis : Tout au long de la conférence, je me suis dit “ça, il faut qu’on le fasse ; et ça aussi ; et ça aussi !” — et depuis, j’ai commencé à brancher quelques métriques ici et là dans nos applications qui, aujourd’hui, ne donnent pas assez d’informations sur ce qu’elles font et comment elles sont utilisées.


REST dans le monde Symfony

William DurandRésumé, Slides, Vidéo

William a commencé par présenter les quatre niveaux du Richardon Maturity Model, en vue de nous montrer que ce que nous faisons généralement n’est pas tellement du REST, mais plus du “HTTP++” :

  • Niveau 0 : HTTP est un tunnel ; cela ressemble à du RPC
  • Niveau 1 : notion d’identité d’objet, les ressources distinctes étant identifiées par leur URI
  • Niveau 2 : introduction des verbes HTTP et des codes de statut, méthodes safes (cachables) et idempotentes (résultat indépendant du nombre d’exécutions).
  • Niveau 3 : découverte de services par le biais de relations et de liens. Négociation de contenus (type, contenu, encodage, langue), Hypermedia (Atom, HAL), HATEOAS (permet de trouver son chemin dans une API)

Il a ensuite passé en revue un ensemble de bundle permettant de créer des API REST (ou “HTTP++”) avec symfony :

  • JMSSerializer : graphes d’objets, documents XML ou JSON
  • FOSRestBundle : boite à outils de services et listeners
  • BazingaHateoasBundle : permet d’atteindre le niveau 3, on définit les relations via des annotations
  • TemplatedUriBundle : niveau 3 aussi ; RFC 6570 : URItemplated
  • NelmioApiDocBundle : génération de documents pour les API à partir de la phpdoc, support d’autres bundles connus
  • LiipCacheControlBundle : ajout de fonctionnalités liées au cache, header Cache-Control et aide pour les proxies — rendu obsolète par FOSHttpCacheBundle
  • Pour OAuth (qui est un protocole d’autorisation et pas d’identification / d’authentification) : HWIOAuthBundle et FOSOAuthServerBundle et BazingaOAuthServerBundle

Mon avis : Ne bossant que peu avec symfony en ce moment et ne mettant pas en place tellement d’API REST, j’ai un peu déconnecté pendant la seconde partie de cette présentation.


Transition agile 4 real @ meetic

Nicolas Kalmanovitz, Thomas DiavetRésumé, Slides, Vidéo

Nicolas et Thomas ont commencé par dresser un rapide historique de l’entreprise : en 2001, 20 personnes (avec du PHP/MySQL “codé en prod”), équipe réactive, les choses marchent pas mal. 2005 entrée en bourse, 2006 rachat de la société. 2011 : 400 personnes dont 100 à la DSI (qui ne produit pas plus que lorsqu’ils étaient 10), équipes qui se critiquent les unes les autres, les choses sont compliquées.

Conséquence : en 2011, volonté de rompre avec le cycle en V, de passer à des méthodes agiles en vue d’améliorer la communication et la productivité. En parallèle, beaucoup de dette technique, plate-forme en PHP 4 procédural, monolithique, “pas le temps d’upgrader”, avec des outils maison, des équipes en silos, … Le “modèle startup” ne fonctionne pas avec 400 personnes.

Sur le gros de la présentation, Thomas et Nicolas ont raconté comment Meetic a effectué cette transition :

  • Tout d’abord, aller vers l’agilité, en scrum (donc : sprints, rituels, démos, …) : approche structurée, simple, efficace. Facile à apprendre. Rupture (et volonté de changer) par rapport à l’ancienne méthode.
  • Equipe scrum : Product Owner (duo composé d’un chef de projet et d’un chef de produit), Scrum Master, développeurs, intégrateur, testeur (pour sécuriser le livrable dès le développement) : tout le monde ensemble.
  • Mise en place de 8 équipes scrum et d’une équipe kanban. Approche “on livre peu, mais on livre souvent”
  • Premiers changements : git + branches (au lieu de SVN et cris à travers l’open-space pour dire qui “lockait” un fichier) et tests manuels mutualisés (sur paquet de release, toutes les deux semaines)

Avec ces premiers pas, en 2012, les équipes ont gagné en autonomie, communication, priorisation et qualité ; l’entreprise a retrouvé la croissance.

Toutefois, il reste encore pas mal de problèmes :

  • de l’accompagnement est requis pour aller au bout de la méthode,
  • l’idée de “double-PO” entraine un chevauchement des responsabilités,
  • la méthode agile n’a été mise en place qu’à la R&D, entrainant un fossé qui grandit par rapport aux autres équipes (et finalement, on retombe dans les anciens problèmes),
  • le time to market n’est pas optimal : il est difficile d’itérer, les releases sont longues à tester et chaque problème impacte la release entière.

Pour aller plus loin, passage à Kanban, et pas qu’à la R&D mais à toute la DSI :

  • marche mieux sur les équipes qui étaient déjà agile (en scrum) que sur celles qui ne l’étaient pas du tout,
  • affichage de boards un peu partout dans toutes les équipes ⇒ visibilité de ce qui est en cours,
  • limite de WIP : flux plus rapide et plus fort, pour améliorer le time to market,
  • FIFO (simple, pas de priorisation) + métriques + gestion des points de contention ⇒ livraison continue

Résultat : temps de cycle de dev et de QA divisé par deux, releases plus fréquentes avec moins de bugs (livraisons plus petites).

Et pour aller jusqu’au bout :

  • tout le monde ensemble dans la même salle, avec livraisons quotidiennes, outils collaboratifs et sessions de tests collaboratifs,
  • intervention d’un consultant extérieur : même constat que l’équipe avait déjà fait. Equipes par fonctionnalités, projets pilotes et mesure des résultats, formation et conduite au changement.

Au final, et j’ai beaucoup aimé la conclusion : les équipes travaillent ensemble, en ayant retrouvé ce qui était bien dans la startup il y a dix ans. En bottom-up, c’est possible. Et sinon… La boîte disparait !

Mon avis : Un retour d’expérience intéressant — j’ai reconnu pas mal de points cités, pour les avoir déjà vécu — avec de bonnes pistes d’améliorations, pour peu que chacun ait envie d’avancer (et c’est souvent le cas).


Take a walk on the OPS side

Baptiste DUPAINRésumé, Slides, Vidéo

Baptiste a commencé par indiquer que m6web regroupe de l’ordre de 30 sites, incluant TV online et portails thématiques. Son métier est de faire passer le code de localhost à la production — sur des sites à forte charge.

La première partie de la conférence avait pour but de présenter quelques outils permettant de débugger une application PHP, en production, sans utiliser PHP lui-même :

  • sysdig : enregistre tout ce que fait le système et donc, ce que fait PHP
    • pour enregistrer sysdig -w php.scap (relecture avec -r pour appliquer des filtres)
    • permet aussi d’analyser des requêtes (sql, redis, … ) en live : sysdig -A proc.name=php5-fpm and evt.buffer contains SELECT
  • curl pour regarder les en-têtes HTTP (leurs applications retournent pas mal d’informations sous cette forme) : curl -Iv monsite.com -s | sort

Il est important de surveiller et mesurer ce qu’il se passe sur la plate-forme, typiquement à l’aide d’outils comme statsd et graphite (chez m6web : de l’ordre de 610,000 métriques et plus de 100 dashboard), ou encore :

  • collectd : récupère tout ce qui est système
  • sensu : monitoring distribué, où chaque serveur effectue ses vérifications et les expose à un démon central
  • seyren : alerting basé sur graphite
  • mayday : contextualisation des alertes
  • Oculus (à l’étude) : corrélation entre les problèmes (par exemple : “il y a des erreurs 500 ET un serveur MySQL est tombé”)
  • riemann (à l’étude) : alertes ou actions, en fonction de règles

Il faut aussi donner du sens à ses logs, qui contiennent plein d’informations qui peuvent permettre de comprendre un incident ou de vérifier des comportements :

  • Problématiques de formats : CSV, JSON, pipe-separated, binaire, … + compression dans certains cas
  • Traitement : synchrone ? asynchrone ?
  • Outils de traitement de logs (450 à 750 million de lignes par jour chez m6web. Environ 50% des informations sont utilisées. 40 informations par ligne de log nginx) :
    • Logs HTTP : roadster
    • PHP : scripts Python
    • MySQL : Anemometer
    • Firewall / syslog : Rsyslog central
    • grokdebug.herokuapp.com : pour parser des logs (genre stacktraces PHP) avec des regex
    • En cours d’étude : stack ELK
  • Outillage :
    • ElasticSearch + logstash + Kibana ⇒ pour prendre les logs, les indexer et les présenter
    • R pour les statistiques. En entrée : logs, SQL, CSV, … Quelques exemples d’usage : filtrer les appels lents, statistiques des pays les moins cachés.

En dernière partie, Baptiste a présenté quelques outils permettant de tester son application (si on passe sur Capital, on prend un gros pic de charge) :

  • Tout d’abord, trois types de tests :
    • test de charge = “est-ce que ça tient avec plein d’utilisateurs ?”
    • test de stress = “voir jusqu’où tient l’infra”
    • test de perfs = “qu’est-ce qui est acceptable pour l’expérience utilisateur ?”
  • Quelques outils :
    • Jmeter / gatling, Siege / Wrk, Tsung
    • gor : réplique du traffic (de production par exemple) en temps réel (vers un environnement de test par exemple)

Mon avis : Pas mal d’outils intéressants pour aller plus loin que PHP en lui-même. J’ai découvert sysdig pendant cette conférence et je l’ai déjà utilisé depuis pour trouver la cause d’un problème incompréhensible (sur une appli en JAVA, closed-source, peu documentée et sans log) ^^


Notre environnement de développement n’est plus un bizutage !

Pascal MARTIN, Julien FUSCORésumé, Slides

Pour terminer cette première journée du PHPTour, Julien et moi avons présenté les améliorations qui ont été apportées ces derniers mois à la mise en place de postes de développement chez TEA, The Ebook Alternative, où nous travaillons tous les deux.

Nous sommes parti du constat difficile à accepter que, lorsque j’ai rejoint TEA il y a un peu moins d’un an, il m’a fallu environ deux semaines pour installer mon poste. Nous avons ensuite expliqué comment nous utilisons désormais des outils comme Vagrant, Chef, ou Stow pour rendre cette installation plus facile et beaucoup plus rapide.

Nous avons au final gagné en maitrise de nos environnements, ceux-ci sont plus à jour (ce qui est indispensable si l’on souhaite, par exemple, monter en version de PHP), nous avons plus de liberté d’expérimenter, et l’intégration d’un nouvel arrivant à notre équipe n’est plus perçue comme un bizutage !

Je n’ai pas pris de note pendant la conférence (j’étais un peu occupé ;-) ), mais je vous encourage vivement à parcourir nos slides, en pensant à consulter les notes du présentateur : avant de diffuser ceux-ci, nous avons veillé à rendre ces notes aussi complètes que possibles, afin que les slides apportent un maximum d’informations à ceux qui n’auraient pas pu assister à notre présentation.

Mon avis : Ma première conférence en duo et la première fois que je présentais plus un retour d’expérience qu’un sujet vraiment technique — une expérience plutôt sympa pour moi, que je renouvellerai probablement dans le futur !


Mes notes du second jour de ce PHPTour 2014 devraient être publiées dans quelques jours — le temps de les mettre au propre ;-)


Par Pascal MARTIN le mardi 1 juillet 2014 1 commentaire

Cet article est aussi disponible en français.

Before really talking about internals@: some of you have come see me during the PHPTour (a 2-days event organized in France by the AFUP — it took place this year on June 23rd and 24th in Lyon) to speak about this series of posts I’ve been writing for about a year and a half (about 6 months in English), thank me and encourage me, telling me this allows you to keep track of what’s going on around PHP’s development. Thanks!


June 2014 came back down to a reasonable 493 messages on PHP’s internals@ mailing-list, after a month of May with more than 800 mails, including some long discussions about phpng.

As a graph representing the number of mails per month for the last three years, we’d get (the full history since 1998 is available here):

Number of mails on internals@ these last three years


The release of PHP 5.6 keeps getting closer: on June 6th, Ferenc Kovacs announced beta 4, which should be the last version before the RC phase.

Indeed, two weeks later, PHP 5.6’s firt Release Candidate has been published!


According to RFC: Define PHP 5.3 end of life, the End Of Life of PHP 5.3 is fixed to one year after the release of PHP 5.5 — which took place on June 20th, 2013.

As the last bugfix release of PHP 5.3 has been published six months ago, Stas Malyshev said a last release would be published soon (probably in July), to fix a few remaining bugs.

Ferenc Kovacs noted it would be useful to insist on the fact there will not be any additional future release of PHP 5.3 — and it’s more than about time for people to switch to more recent versions!


Pierre Joye posted about a new tool which is currently being developed, to install PHP extensions: RFC: Pickle.

The mid/long term idea is to remove the pecl PEAR command, and for composer to be able to work with this new pickle tool to install extensions.


Right at the beginning of the month, Andrea Faulds wrote an RFC nammed “Bare Name Array”, which would bring two new syntaxes, a bit shorter than those we use today (like [] is shorter than array()), to work with arrays in PHP.

The first one would allow us to write arrays this way, without changing the current behavior of =>:

$tableau = [
    clef1: "valeur 1",
    clef2: 42,
    clef3: [
        sub1: 25,
        sub2: "aaa",
    ],
];

Later during this conversation, Adam Harvey asked if going farther was possible, setting up something like Ruby’s symbols — which would not be easy in PHP, especially when it comes to syntax.

The second idea would allow us to access array elements this way:

echo $tableau:>clef3:>sub2;

As these two proposals are quite distinct, Levi Morrison noted they should be split in two separate RFCs — and Andrea Faulds quickly created them: RFC: Bare Name Array Literal and RFC: Bare Name Array Dereference.

Votes on these RFCs have been opened after a few additional mails — and they both have been rejected (the first one with 14 “no” votes and 3 “yes” votes, and the second one with 15 “no” votes and no “yes” vote).

Basically, it seems those changes of syntax were not necessary and made the language more complex — having two syntaxes with distinct behaviors was not intuitive.


Last month (in May), a change related to serialization made its way to PHP 5.4.29 and 5.5.13. It caused a break in components such as Doctrine or PHPUnit, on a specific case sometimes used to create objects without the class’ constructor being invoked, (which is kind of a hack, especially when used on internal classes).

Both projects have quickly been updated, but Jakub Zelenka noted it would be interesting to quickly release a fix at PHP’s level itself, both for developers or other projects that might be suffering from the same problem.

As Benjamin Eberlei then said, if PHP was tested on a couple of projects and libraries (and not only on PHP’s tests themselves) before each release, this kind of regression could have been avoided1. That being said, as Johannes Schlüter answered, it would be helpful if developers using PHP were testing RC versions and posting feedback a bit more — which is not always easy and could be made easier if nightly versions of PHP were available on Travis CI.

The discussion about the solution that should be implemented mig/long-term lasted a bit of time — during which Travis CI switched to the last version of PHP, causing failures in PHPUnit tests on several projects. Still, Ferenc Kovacs insisted on the fact that pushing a fix too rapidly was not necessarily the best thing to do.

In the end, a basic solution has been implemented for PHP 5.4 and 5.5 in order to fix projects that were suffering from this break. A more complete solution will then be implemented for PHP 5.6.


Nikita Popov wrote the RFC: Uniform Variable Syntax, which aims to get a more consitent and complete syntax for variables, for PHP 62.

Even if the discussion hasn’t been long, the feedback has been quite positive. It has even been suggested some checks could be added in PHP 5.7 to facilitate detection of points that will likely break in the future.


Pierre Joye reminded us the security that corresponds to the open_basedir directive can be obtained by setting up permissions at the system level, be it with Windows or Linux — which means the effort required to maintain that directive might not be that useful. As a consequence, he suggested it could be removed for PHP 6.

Julien Pauli quickly answered it was indeed not needed anymore, it was easy to circumvent, and that removing it would allow for some cleaning up in several portions of PHP’s source code.

Still, even if open_basedir doesn’t bring a real level of security, this feature mitigates the risk for some kind of bugs to be exploited and facilitates their detection. Actually, provided developers use PHP’s streams properly and don’t think open_basedir is related to security, keeping this directive could be interesting.


The RFC: Fix handling of custom session handler return values passed for PHP 5.7, with 10 “yes” votes and zero “no” vote.

At the end of the month, Timm Friebe annouced votes were opened on RFC: Catchable “call to a member function of a non-object”. If this RFC passes, calling a method on something that’s not an object (like NULL, for examples) will trigger a E_RECOVERABLE_ERROR instead of a Fatal Error.

Andrea Faulds wrote the RFC: Big Integer Support, which aims to keep working with integers even for very large values, where PHP now falls back to floats when values don’t fit in the range integers can represent. The first answers have been rather positive, even if some points still need clarifications before the RFC can go forward in the next weeks.

David Zuelke posted a fix that will allow php-fpm to work better with Apache.

Finally, after an RFC about anonymous classes has been rejected some time ago, Sebastian Bergmann re-started discussions on this idea, with a case in which he thinks they could be useful (for tests). I’m curious to see if, this time, the idea will go farther — maybe PHP 6 could help with that?



internals@lists.php.net is the mailing-list of the developers of PHP; it is used to discuss the next evolutions of the language and to talk about enhancement suggestions or bug reports.
This mailing-list is public and anyone can subscribe from the page Mailing Lists, or read its archives using HTTP from php.internals or through the news server news://news.php.net/php.internals.



  1. Actually, it seems this change had been identified before, but had then been forgotten in the discussions. 

  2. As this proposal can break some use-cases (which are rarely worked with), it cannot target a minor version such as PHP 5.7. 

Par Pascal MARTIN le mardi 1 juillet 2014 1 commentaire

This post is also available in English.

Avant de réellement parler de dépilage d’internals@ : vous avez été nombreux à venir me voir tout au long du PHPTour (qui a eu lieu, cette année, les 23 et 24 juin à Lyon) pour me parler de cette série d’articles que je publie depuis maintenant un an et demi, me remercier et m’encourager, en indiquant que cela vous permettait de savoir ce qu’il se passait autour du développement de PHP. Ça fait plaisir et chaud au cœur ; merci à vous tous !


Juin 2014 est redescendu à un volume raisonnable de 493 messages sur la mailing-list internals@ de PHP, après un mois de mai qui avait été animé par plus de 800 mails, dont de longues discussions autour de phpng.

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

Nombres de mails sur internals@ ces trois dernières années


La sortie de PHP 5.6 continue de se rapprocher : le 6 juin, Ferenc Kovacs a annoncé la bêta 4, qui devrait être la dernière version avant la phase de RC.

Et deux semaines plus tard, la première Release Candidate de PHP 5.6 a été publiée !


Comme décidé via la RFC: Define PHP 5.3 end of life, la fin de vie de PHP 5.3 devrait arriver un an après la sortie de PHP 5.5 — qui a eu lieu le 20 juin 2013.

La dernière release corrective de PHP 5.3 ayant été publiée il y a six mois, Stas Malyshev a annoncé qu’une toute dernière version serait publiée prochainement (probablement en juillet) en vue de corriger quelques derniers problèmes.

Ferenc Kovacs a noté qu’il faudrait alors insister sur le fait qu’il n’y aurait ensuite plus de nouvelle version de PHP 5.3 — et qu’il était temps pour tout le monde de migrer vers une version plus récente !


Pierre Joye a indiqué qu’un nouvel outil d’installation d’extensions était en cours de développement : RFC: Pickle.

A moyen/long terme, l’idée est de supprimer la commande pecl de PEAR et que composer soit capable d’utiliser ce nouvel outil pickle pour installer des extensions.


En tout début de mois, Andrea Faulds a rédigé une RFC nommée “Bare Name Array”, qui apporterait deux nouvelles syntaxes, légèrement plus courtes que celles existant aujourd’hui (un peu comme [] est plus court que array()), pour manipuler des tableaux en PHP.

La première permettrait de déclarer des tableaux de la manière suivante, tout en ne changeant pas le comportement actuel de => :

$tableau = [
    clef1: "valeur 1",
    clef2: 42,
    clef3: [
        sub1: 25,
        sub2: "aaa",
    ],
];

Plus loin dans la conversation, Adam Harvey a demandé s’il avait été envisagé d’aller plus loin, en mettant en place quelque chose s’approchant des symboles de Ruby — ce qui ne serait pas évident en PHP, notamment en termes de syntaxe.

La seconde proposition permettrait quant à elle d’accéder aux éléments d’un tableau comme ceci :

echo $tableau:>clef3:>sub2;

Ces deux propositions n’étant pas réellement liées, Levi Morrison a fait remarquer qu’elles devraient être découpées en deux RFC distinctes — et Andrea Faulds les a rapidement créées : RFC: Bare Name Array Literal et RFC: Bare Name Array Dereference.

Les votes sur ces deux RFC ont été ouverts après quelques échanges supplémentaires — et elles ont toutes deux été rejetées (la première avec 14 votes contre et 3 votes pour, et la seconde avec 15 votes contre et aucun vote pour).

Dans l’ensemble, les retours ont principalement insisté sur le fait que ces modifications de syntaxe n’étaient pas nécessaires et rendaient le langage plus complexe — et sur le fait qu’avoir deux syntaxes avec des comportements différents était peu intuitif.


Le mois dernier (en mai, donc), une modification apportée à PHP 5.4.29 et 5.5.13 au niveau de la désérialisation, sur un cas particulier parfois utilisé pour créer des objets sans que le constructeur de la classe correspondante ne soit invoqué (ce qui est un gros hack, surtout sur des classes internes), a entrainé une cassure au sein de briques comme Doctrine ou PHPUnit.

Les deux projets en question ont rapidement été adaptés, mais Jakub Zelenka a souligné qu’il serait bon de sortir rapidement un correctif au niveau de PHP lui-même, que ce soit pour les développeurs ou les autres projets souffrant éventuellement du même problème.

Comme l’a fait remarquer Benjamin Eberlei, si PHP était testé sur une série de projets et bibliothèques (et pas uniquement sur les tests de PHP lui-même) avant chaque nouvelle version, ce type de régression aurait pu être évité1. Cela dit, comme l’a souligné Johannes Schlüter, il serait utile que les développeurs utilisant PHP prennent la peine de tester un peu plus les versions RCs et de faire des retours — ce qui n’est pas forcément simple et pourrait être facilité si des versions nightly de PHP étaient disponibles sur Travis CI.

La discussion autour de la solution à mettre en place à moyen/long terme a duré quelques temps — alors que Travis CI a appliqué la dernière version de PHP, entrainant des échecs de tests PHPUnit sur plusieurs projets. En même temps, Ferenc Kovacs a insisté sur le fait que sortir un correctif à la hâte n’était pas forcément non plus la meilleure chose à faire.

Au final, une solution basique a été mise en place pour PHP 5.4 et 5.5 de manière à réparer les projets impactés. Une solution plus complète sera mise en place pour PHP 5.6.


Nikita Popov a rédigé la RFC: Uniform Variable Syntax, qui vise à introduire en PHP 62 une syntaxe plus homogène et complète pour les variables.

Bien que la discussion n’ait pas été très longue, les retours ont été plutôt positifs, allant jusqu’à suggérer l’ajout de vérifications dès PHP 5.7 pour détecter les points qui casseront dans le futur.


Pierre Joye a rappelé que la sécurité correspondant à la directive open_basedir pouvait être mise en place en réglant les permissions au niveau du système, que ce soit sous Windows ou sous Linux et que l’effort à fournir pour maintenir celle-ci n’en valait peut-être donc pas la peine. En conséquence, il a proposé de supprimer cette directive pour PHP 6.

Julien Pauli a rapidement répondu qu’elle n’était effectivement plus nécessaire, qu’elle était facile à contourner, et que la supprimer permettrait de nettoyer plusieurs portions du code source de PHP.

Toutefois, même si open_basedir n’apporte pas un réel niveau de sécurité, cette fonctionnalité permet de mitiger le risque d’exploitation de bugs et de les détecter. En fait, pour peu que les développeurs utilisent correctement les flux de PHP et n’affirment pas qu’open_basedir est une directive en lien avec la sécurité, la conserver pourrait être intéressant.


La RFC: Fix handling of custom session handler return values est passée pour PHP 5.7, avec 10 votes “pour” et aucun vote “contre”.

En toute fin de mois, Timm Friebe a annoncé l’ouverture des votes sur la RFC: Catchable “call to a member function of a non-object”. Si cette RFC passe, appeler une méthode sur quelque chose qui n’est pas un objet (comme NULL, par exemple) entrainera la levée d’une E_RECOVERABLE_ERROR à la place d’une erreur fatale.

Andrea Faulds a rédigé la RFC: Big Integer Support, qui propose de continuer à travailler avec des nombres entiers même pour de très grandes valeurs, là où PHP se rabat aujourd’hui sur des nombres flottants lorsque les valeurs manipulées ne tiennent pas dans la plage que les entiers peuvent représenter. Les premiers retours ont été plutôt positifs, même s’il reste des points à éclaircir avant que la RFC ne puisse continuer à avancer sur les prochaines semaines.

David Zuelke a posté quelques corrections qui permettront à php-fpm de mieux fonctionner avec Apache.

Et enfin, alors qu’une RFC sur l’idée de classes anonymes avait été rejetée il y a un moment de cela, Sebastian Bergmann est revenu à la charge sur le sujet, avec un cas où il voit leur utilité (pour la mise en place de tests). Je suis curieux de voir si, cette fois, l’idée ira plus loin — peut-être que PHP 6 pourrait faire pencher la balance dans l’autre sens ?



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.



  1. En pratique, il semblerait que ce changement avait été identifié auparavant, mais qu’il ait ensuite été oublié dans la discussion. 

  2. Cette proposition peut casser quelques cas d’usages (rarement employés) et ne peut donc pas cibler une version mineure. 

Par Pascal MARTIN le mercredi 25 juin 2014 1 commentaire

Les slides que Julien Fusco et moi avons utilisés comme support pour notre conférence « Notre env. de dév. n’est plus un bizutage ! » au PHPTour 2014 à Lyon sont disponibles en ligne : Notre env. de dév. n’est plus un bizutage !.

Pour ceux qui voudraient plus d’informations que les slides en eux-même, nous avons noté quelques points dans les notes du présentateur, accessibles via la touche s.

Et si vous étiez présent au PHPTour et que vous avez assisté à cette conférence, nous sommes bien entendu preneur de tout retour — vous pouvez retrouver toutes les conférences, dont celle-ci, sur joind.in.

Par Pascal MARTIN le mercredi 25 juin 2014 2 commentaires

Les slides que j’ai utilisés comme support pour ma conférence « PHP 5.3 → 5.6 : No pain but gain ! » au PHPTour 2014 à Lyon sont disponibles en ligne : PHP 5.3 → 5.6 : No pain but gain !.

Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s.

Et si vous étiez présent au PHPTour et que vous avez assisté à cette conférence, je suis bien entendu preneur de tout retour — vous pouvez retrouver toutes les conférences, dont celle-ci, sur joind.in.

Par Pascal MARTIN le jeudi 5 juin 2014

Cet article est aussi disponible en français.

The month of May 2014 that’s just ended has seen 816 messages on PHP’s internals@ mailing-list. After a calm month of April, we’re back to a higher volume of discussions!

As a graph representing the number of mails per month for the last three years, we’d get (the full history since 1998 is available here):

Number of mails on internals@ these last three years


First of all: the release of PHP 5.6 keeps getting closer: Ferenc Kovacs announced beta 2 on May 2nd. It’s been followed by beta 3 the 15th.


Right at the beginning of the month, Dmitry Stogov started writing about a series of changes, named phpng, that would allow a great performance gain: up to 10% to 30%, depending on the applications.

The initial idea started with the fact the PHP engine works with data-structures that always require memory allocations and reference counting — a typical PHP application can spend 20% of its CPU time managing memory, 10% manipulating HashTables, 30% in internal functions and only 30% in the VM. Reworking internal data-structures to minimize memory allocations should help with that.

This means a great deal of refactoring (4 months of work) has been done on the PHP engine. It improves performance, memory usage, and sets up the first steps that could be used as a foundation for other future evolutions, such as JIT compiling.

This work is, of course, not finished yet (it would require at least a couple of months before one could consider it as alpha), but people quickly suggested it could be one of the big things for PHP 6 — which could be released in something like two years.

phpng should not have any impact on behavior has seen by users, but it will require updates on all PHP extensions to adapt them (changes on data-structures used internally by PHP have to be taken into account by extensions, as they are close to PHP itself). To document the migration to phpng for developers of PHP or extensions, a wiki page has been initialized: Upgrading from PHP5 to NG.

During the conversation, the idea of removing old SAPIs has been talked about once again — some going as far as suggesting that mod_php should not be supported anymore, as it’s often better to replace it with Apache/mod_fcgid or nginx/php-fpm. Still, even if those have a better architecture, one must not forget that swapping a component has a cost.


Pierre Joye quickly noticed the phpng branch conflicts with the work done since several months on 64 bits support (it has not been merged to PHP 5.x branch as it brings too many changes). To prevent this kind of situation from happening again, it really is necessary to communicate more — and working in an open mode would allow more developers to help.

He then posted a few numbers about the impact the 64bits branch has on memory usage: it needs between 2% and 5.5% more memory on real applications. The relative impact would be greater with the phpng branch, as it changes several internal data-structures. If you want to know more, here are a few notes about the goals of this branch.

A bit later, Anatol Belski announced votes were opened on the corresponding RFC: 64 bit platform improvements for string length and integer in zval. In the thread, Ferenc Kovacs summarized part of the problem: on one side, phpng aims to improve performances and reduce memory usage, and, on the other side, the 64bits branch aims to get better internal typing while using a bit more memory.

As discussions weren’t really constructive anymore, Nikita Popov suggested to find a common ground, using some evolutions from the 64bits branch (64 bits integers, unsigned-sizes, size_t for strings’ length) but not going to 64 bits where it costs too much memory and corresponds to less interesting features (lines numbers, numbers of parameters, HashTables sizes).

This proposal has been quite appreciated. As Rasmus Lerdorf answered, this idea is coherent and takes into account work done on both sides. Because of problems with the mailing-list, a new RFC has not been created right away and sould land soon.


At the end of the month, after a post writen by Joe Watkins about phpng had appeared on php.net, Ferenc Kovacs asked what should be done about it: keep it as-is, delete it, re-write it to be more formal and more factual, or post another article clarifying the matter is still subject to controversy and this post was more the personal opinion of one developer than an official statement.

Several expressed their surprise about this post, as php.net is not supposed to be used as a personal blog. In addition, as many websites had already re-posted the news, just deleting it did not seem to be the best approach — but, in the same time, it’s probably too early to begin talking officially about these evolutions and this post was not really formulated in a way that was objective and professional.

Still, as Philip Sturgeon said, several high-traffic websites had already started talking about phpng — not always successfully summarizing what it is and what it means for the future of PHP (and, of course, posting about PHP in a negative way is often a good way to generate traffic).

Levi Morrison then brought some explanations about the idea behind this post: as “phpng” was being talked about in the community, bringing some clarifications about it was a reasonable idea. In a way, it could be perceived as an attempt to communicate towards developers using PHP, about what was being discussed on internals@1; and trying to move forward is never easy.

Joe Watkins added he didn’t intend to post a news on php.net and was trying to launch a developers blog. This idea, by the way, is close to one of the missions of planet-php. In fact, this idea of “blog of developers”, with posts about what’s happening around the development of PHP and internals@, is kind of what I didn’t find when I begun posting these digests — even if it would be interesting having posts going farther into details, less in a “digest” mode.

In the end, Zeev Suraski removed the entry from the homepage of php.net so it has less visibility, keeping it in the archives 2014 — which was pretty much the right thing to do for many people.


Dmitry Stogov wrote the RFC: Fast Parameter Parsing API which would bring a faster alternative to zend_parse_parameters()2 to read parameters of a function or method.

Introducing a large amount of new macros and a more verbose syntax seems to be of interest to some, but others noted this would lead to heavier code. As Pierre Joye said, it would also be great to clean internal APIs: a more pleasing code-base would facilitate work for the next 10 years.

On the other hand, a gain of a few percents (between 2% and 5%) on performances, while only updating the most important functions… In effect, The RFC should insist of the fact the idea is to update only a few functions of PHP.


Stas Malyshev announced the RFC: Keeping PHPT Tests Green had passed, with 16 “yes” votes and no vote “against”. When a test doesn’t pass anymore, two solutions are possible: revert the change that broke it (after two days), or update the test. Of course, the second option should only be chosen when the new behavior is expected.

In the following days, Stas Malyshev sent some mails when changes broke the build, asking for the corresponding problems to be fixed. Reactions have been quite positive, and this should be a good thing for stability.


Andrea Faulds indicated that, in order to pass, an RFC needs 50%+1 votes “for” — and 2/3 votes “for” if it’s about a change that impacts the language itself. That being said, he noted that “change impacting the language” is not always easy to judge and that “50%+1 to pass” means some RFCs can be accepted even if they only have a small majority.

As a consequence, he proposed that all RFCs could now require 2/3 of “yes” votes in order to pass. This way, only changes well accepted by developers would pass (in effect, all RFCs that have been accepted for PHP 5.6 had at least 2/3 of “yes” votes — which means this idea would not really stop PHP from evolving).

Zeev Suraski answered that 50%+1 was, in his opinion, good enough for changes on extensions, functions, version numbers — basically, for targeted changes with no impact on the general direction PHP is going to. On the other hand, it could be interesting if only developers really concerned by a change could vote on it (for instance, developers working on the engine would vote for a central change, while those working on documentation would vote on changes linked to it). Still, as Andrea Faulds answered, changes on the Zend layer will tend to impact everyone.

Actually, as Dmitry Stogov indicated, some changes on the engine require a real technical expertise to be understood. And this technical expertise could help getting to better solutions — which is something that’s sometimes being done, as several recent RFCs have been written by teams of developers, with newcomers being guided by more ancient ones.

In the end, judging for the discussion, these 50%+1 and 2/3 will probably remain as they are today — and the distinction between the two types of RFCs should be made more clear.


A few mails arrived in the thread about the RFC: Return Type Declarations. Mainly, the proposed syntax has the advantage of being similar to what’s used by other languages and to be compatible with the one chosen by Hack.

Josh Watzman posted some notes about some incompatibilities between this RFC and Hack’s implementation. For example, Hack uses this as return type where PHP would prefer self.


After points of views had sometimes been expressed with a bit of vehemence, Levi Morrison reminded us that, even if each one can have his own vision of how PHP could be improved, the goal of everyone is the same — and he posted a list of a few points he considers as OK or not.

Martin Keckeis suggested for PEAR to not be integrated to PHP’s sources anymore. Still, as Hannes Magnusson answered, PEAR is also used to install PECL extensions — which means it is still useful and cannot be removed for now.

Michael Wallner said he started thinking about the loading of extensions that depend on others (today, it’s up the the user to deal with that himself, to load those extensions in the right order). Julien Pauli answered that something had been started on the subject a while ago and it could be interesting to share ideas. As a matter of facts, as noted by Hannes Magnusson, the extension mechanism might need more work than this single point!

Sara Golemon wrote the RFC: Add typehint accessors to ReflectionParameter which aims to have better handling of type-hints when using Reflection. Levi Morrison noted that taking into account the RFCs on return types and nullable types could be useful too; and, as a consequence, the RFC has been updated.

Sara Golemon also wrote the RFC: Fix handling of custom session handler return values — as the corresponding fix breaks backward-compatibility, an RFC can be required (at least, to decide for which PHP version this can be done).



internals@lists.php.net is the mailing-list of the developers of PHP; it is used to discuss the next evolutions of the language and to talk about enhancement suggestions or bug reports.
This mailing-list is public and anyone can subscribe from the page Mailing Lists, or read its archives using HTTP from php.internals or through the news server news://news.php.net/php.internals.



  1. Johannes Schlüter noted I had been doing a monthly digest of internals@ for some time — and also in English after a little push by Ferenc Kovacs. 

  2. zend_parse_parameters() is the C function used internally by all functions of PHP and its extensions when they need to receive parameters. This changes would, as a consequence, be invisible for developers using PHP. 

Par Pascal MARTIN le jeudi 5 juin 2014

This post is also available in English.

Le mois de mai 2014 qui vient de se terminer a vu 816 messages sur la mailing-list internals@ de PHP. Après un mois d’avril bien calme, on repart sur un volume d’échanges nettement plus important !

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

Nombres de mails sur internals@ ces trois dernières années


Avant tout : la sortie de PHP 5.6 continue d’approcher : Ferenc Kovacs a annoncé la bêta 2 le 2 mai. Et elle a été suivie de la bêta 3 le 15.


Alors que le mois venait tout juste de commencer, Dmitry Stogov a commencé à parler d’une série de modifications, nommées phpng, qui permettrait un gain de performance allant de 10% à 30% selon les applications.

Le constat initial partait du fait que le moteur d’exécution de PHP travaille avec des structures de données demandant sans cesse d’effectuer des allocations/libérations mémoire et du comptage de références — une application PHP typique pouvant passer 20% de son temps CPU en gestion de mémoire, 10% en manipulation de HashTables, 30% en fonctions internes et seulement 30% dans la VM. Une amélioration serait donc de modifier les structures de données utilisées en interne, en vue de minimiser les allocations mémoires.

Cela signifie un gros travail de refactoring (4 mois de travail) sur le moteur de PHP, qui améliore les performances, l’utilisation mémoire et pose les premières briques qui pourront servir de fondations à d’autres améliorations futures, comme la mise en place de compilation JIT.

Ce travail n’est bien sûr pas terminé (il demanderait encore quelques mois avant de pouvoir être présentable en version alpha), mais il a rapidement été suggéré qu’il pourrait s’agir d’un gros point pour PHP 6 — qui est prévue pour dans quelque chose comme deux ans.

Là où phpng ne devrait pas avoir d’impact sur le comportement tel qu’il est vu côté utilisateur, il faudrait par contre repasser sur l’ensemble des extensions PHP existantes en vue de les adapter (les changements sur les structures de données utilisées en interne par PHP sont à prendre en compte au niveau des extensions, celles-ci étant assez proches de PHP lui-même). En vue de documenter la migration vers phpng pour les développeurs de PHP ou d’extensions, une page wiki a d’ailleurs été mise en place : Upgrading from PHP5 to NG.

Dans la conversation est revenue l’idée qu’il serait intéressant de se débarrasser des vieilles SAPIs — certains allant jusqu’à suggérer de ne plus supporter mod_php, qui gagne souvent à être remplacé par Apache/mod_fcgid ou nginx/php-fpm. Toutefois, même si ces derniers suivent une architecture mieux conçue, n’oublions pas que changer un composant a un coût.


Pierre Joye a rapidement noté que la branche phpng entrait en conflit avec le travail effectué depuis plusieurs mois sur le fonctionnement de PHP en 64 bits (qui n’a pas été intégré à la branche PHP 5.x car apportant trop de modifications). En vue d’éviter que ce type de cas de figure se reproduise, il faudrait grandement améliorer la communication — de plus, travailler sur un mode ouvert permettrait à plus de développeurs d’intervenir.

Il a ensuite posté quelques chiffres indiquant comment la branche 64bits impactait l’utilisation mémoire : entre 2% et 5.5% de mémoire utilisée en plus sur des applications réelles. L’impact relatif serait plus important avec les modifications apportées par la branche phpng, celle-ci ayant revu plusieurs structures de données internes. En complément pour ceux qui voudraient en savoir plus, voici quelques notes sur le but de cette branche.

Dans la foulée, Anatol Belski a annoncé en milieu de mois l’ouverture des votes sur la RFC correspondante : 64 bit platform improvements for string length and integer in zval. Dans la discussion, Ferenc Kovacs a résumé une partie du problème : d’un côté, phpng vise à améliorer les performances et à réduire l’occupation mémoire, alors que la branche 64bits vise à améliorer les typages internes tout en augmentant celle-ci.

Constatant que les discussions tournaient en rond et n’étaient plus réellement constructives, Nikita Popov a proposé de trouver un terrain d’entente, en mettant en place certaines des évolutions apportées par la branche 64bits (entiers en 64 bits, tailles non-signées, size_t pour les longueurs de chaînes) mais sans pour autant basculer en 64 bits là où c’est le plus coûteux en mémoire et le moins intéressant en fonctionnalité (numéros de lignes, nombres de paramètres, tailles de HashTables).

Cette proposition a été plutôt bien accueillie. Comme l’a souligné Rasmus Lerdorf, la solution est cohérente et prend en compte le travail effectué des deux côtés. En raison de problèmes au niveau de la mailing-list, une nouvelle RFC n’a pas pu être soumise immédiatement et devrait arriver prochainement.


En fin de mois, alors qu’un post rédigé par Joe Watkins à propos de phpng était apparu sur php.net, Ferenc Kovacs a demandé ce qu’il fallait en faire : le conserver tel quel, le supprimer, le ré-écrire afin qu’il soit plus formel et plus factuel, ou poster un autre article expliquant que ce premier était encore sujet à controverses et qu’il s’agissait plus de l’avis personnel d’un développeur que d’une déclaration officielle.

Plusieurs ont exprimé leur surprise quant à la mise en ligne de cet article, php.net n’ayant pas pour but de jouer un rôle de blog personnel. De plus, pas mal de sites ayant repris la nouvelle, simplement supprimer celle-ci ne semblait pas forcément être la meilleure approche pour tous — mais, en même temps, il est probablement bien trop tôt pour commencer à parler de ces évolutions de manière officielle et cet article n’était d’après certains pas vraiment formulé de manière objective ni professionnelle.

Toutefois, comme l’a souligné Philip Sturgeon, plusieurs sites à fort trafic avaient déjà commencé à parler de phpng — sans nécessairement parvenir à résumer avec succès ce dont il s’agit et les implications futures pour PHP (et, bien sûr, parler de PHP en termes peu flatteurs est souvent un bon moyen pour générer du trafic).

Levi Morrison a ensuite apporté quelques explications quant à l’origine de cet article : alors que “phpng” faisait parler de lui dans la communauté, apporter quelques éclaircissements était en soit une idée raisonnable. En quelque sorte, il pouvait s’agir d’une tentative de communication auprès des développeurs utilisant PHP, autour de ce qu’il se passait sur internals@1 ; et essayer d’avancer n’est jamais facile.

Joe Watkins a complété en indiquant qu’il n’avait pas souhaité poster une news sur php.net mais qu’il visait à lancer un blog de développeurs. Cette idée, d’ailleurs, est un peu liée à un des rôles de planet-php. En fait, cette idée de “blog de développeurs” parlant de ce qu’il se passe autour du développement de PHP et d’internals@, c’est un peu ce qu’il me manquait quand j’ai commencé à poster ces dépilages — même s’il serait intéressant d’avoir des articles allant plus au fond des choses, moins en mode “résumé”.

Finalement, Zeev Suraski a supprimé l’entrée de la page d’accueil de php.net pour lui retirer un peu de visibilité, tout en laissant l’article sur la page d’archives 2014 — ce qui était la chose à faire pour pas mal de monde.


Dmitry Stogov a rédigé la RFC: Fast Parameter Parsing API qui vise à mettre en place une solution alternative, plus rapide, à zend_parse_parameters()2 pour la lecture des arguments d’une fonction ou méthode.

En pratique, introduire une grande quantité de nouvelles macros et une syntaxe plus verbeuse semble en intéresser certains, mais d’autres ont fait remarquer que cela rendait aussi le code plus lourd à écrire. Comme l’a souligné Pierre Joye, il serait bon d’améliorer les API internes : une base de code plus agréable faciliterait le travail sur les 10 prochaines années.

D’un autre côté, un gain de quelques pourcents (entre 2% et 5%) au niveau des performances, en ne modifiant que les fonctions les plus importantes… Il faudrait d’ailleurs que la RFC insiste sur le fait qu’il ne s’agit de modifier qu’une petite partie des fonctions de PHP.


Stas Malyshev a annoncé que la RFC: Keeping PHPT Tests Green était passée, avec 16 votes pour et aucun vote contre. En cas de test ne passant plus, les deux solutions qui ressortent sont d’annuler les modifications problématiques au bout de deux jours ou de mettre à jour les tests. Bien sûr, la seconde option ne doit être retenue que lorsque le nouveau comportement est attendu.

Dans les jours qui ont suivi, Stas Malyshev a envoyé des mails lorsque des modifications cassaient le build, demandant à ce que les problèmes correspondant soient corrigés. Les réactions ont été plutôt bonnes et la stabilité ne peut qu’en être améliorée.


Andrea Faulds a rappelé que pour passer, une RFC avait besoin de 50%+1 votes “pour” — et de 2/3 de votes “pour” dans le cas d’une modification impactant le langage en lui-même. Cela dit, il notait que la distinction “changement impactant le langage” n’était pas toujours claire et qu’une majorité de 50%+1 signifiait que des RFC pouvaient passer à une très faible majorité.

En conséquence, il a proposé que toutes les RFC aient désormais besoin de 2/3 de votes “pour” pour être acceptées. De la sorte, seules les modifications réellement bien acceptées par les développeurs passeraient (en pratique, toutes les RFC passées pour PHP 5.6 avaient au moins 2/3 de “pour” — cette proposition ne constituerait donc pas un réel frein au progrès).

Zeev Suraski a répondu que 50%+1 était selon lui suffisant pour des modifications sur des extensions, des fonctions, des numéros de versions — en somme, des points précis n’impactant pas la direction générale de PHP. Par contre, il lui semblerait intéressant que seuls les développeurs réellement concernés par une modification votent sur celle-ci (par exemple, ceux travaillant sur le moteur voteraient pour une modification centrale, alors que ceux travaillant sur la documentation interviendrait en cas de changement sur celle-ci). Toutefois, comme l’a fait remarquer Andrea Faulds, les changements sur la couche Zend vont avoir tendance à impacter tout le monde.

En fait, comme noté par Dmitry Stogov, certaines modifications au niveau du moteur demandent une réelle expertise technique pour être comprises. Expertise technique qui pourrait aider à arriver à de meilleures solutions — ce qui commence à se faire, puisque plusieurs RFC récentes ont été rédigées par des équipes de plusieurs développeurs, avec de nouveaux arrivant guidés par des plus anciens.

Finalement, au vu des échanges, il est probable que ces 50%+1 et 2/3 restent comme ils sont aujourd’hui — mais que la distinction entre les deux types de RFC soit éclaircie.


Quelques échanges sont venus compléter la discussion tournant autour de la RFC: Return Type Declarations. En particulier, la syntaxe proposée a l’avantage d’être similaire à celle d’autres langages ainsi que d’être compatible avec celle retenue par Hack.

Josh Watzman a posté quelques retours où il relevait quelques incompatibilités entre cette RFC et l’implémentation choisie pour Hack. En particulier, Hack utiliserait this comme type de retour là où PHP partirait plutôt sur self.


Alors que des points de vue différents ont parfois été exprimés assez brutalement, Levi Morrison a rappelé que même si chacun pouvait avoir une vision différente de la manière dont il est possible d’améliorer PHP, le but de tous était le même — et a dressé une rapide liste de quelques points qu’il jugeait acceptables ou non.

Martin Keckeis a proposé que PEAR ne soit plus intégré aux sources de PHP. Toutefois, comme répondu par Hannes Magnusson, PEAR permet aussi l’installation d’extension PECL — ce qui signifie qu’il n’est pas possible de s’en passer pour l’instant.

Michael Wallner a indiqué avoir commencé à réfléchir au chargement d’extensions dépendant les unes des autres (aujourd’hui, c’est à l’utilisateur de se débrouiller pour charger ces extensions dans le bon ordre). Julien Pauli a répondu que quelque chose avait été commencé sur le sujet il y a quelques temps et qu’il pourrait être intéressant de mettre ces idées en commun. En fait, comme l’a souligné Hannes Magnusson, le mécanisme d’extensions aurait peut-être besoin de plus d’améliorations que ce seul point !

Sara Golemon a rédigé la RFC: Add typehint accessors to ReflectionParameter qui vise à améliorer la façon dont sont gérés les type-hints par la Reflection. Levi Morrison a souligné qu’il pourrait être intéressant de voir ce que donnent les deux RFC sur les types de retours et les types nullables ; et la RFC a été mise à jour en conséquence.

Sara Golemon a aussi rédigé la RFC: Fix handling of custom session handler return values — la correction correspondante cassant la compatibilité antérieure, une RFC peut être nécessaire (ne serait-ce que pour déterminer pour quelle version de PHP cette modification pourrait être apportée).



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.



  1. Johannes Schlüter a au passage souligné que j’effectuais un dépilage mensuel d’internals@ depuis quelques temps — et aussi en anglais suite à un petit échange avec Ferenc Kovacs. 

  2. zend_parse_parameters() est la fonction C utilisée en interne par toutes les fonctions de PHP et de ses extensions lorsqu’elles ont besoin de recevoir des paramètres. Ce changement serait donc invisible pour les développeurs utilisant PHP. 

Par Pascal MARTIN le lundi 2 juin 2014 1 commentaire

Lors de l’ApéroPHP lyonnais du 27 mai 2014, j’ai eu l’occasion de donner une présentation de HHVM et Hack. Après quelques mots sur le moteur d’exécution HHVM, j’ai passé en revue une partie des points que le langage Hack apporte par rapport à PHP.

Les slides que j’ai utilisés comme support sont disponibles en ligne1 : HHVM et Hack : slides de ma présentation à l’AperoPHP lyonnais du 27 mai.


Puisque le sujet a été abordé après la présentation, je profite de ce post pour rappeler que 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.


Et, aussi pour rappel : toutes les fin de mois2, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou :

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.



  1. Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s

  2. En théorie, les ApéroPHP lyonnais ont lieu le 29 de chaque mois. En pratique, la date varie un peu, mais c’est généralement vers la fin du mois. Rendez-vous sur aperophp.net, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon