Par Pascal MARTIN le mercredi 17 septembre 2014 3 commentaires

Je serai présent au Forum PHP 2014 les 23 et 24 octobre à Paris !


Cette année, j’animerai une session de questions/réponses autour de PHP, de son état et de son évolution, à laquelle participeront trois intervenants :

  • Jordi Boggiano (Lead Developer de Composer), que je rencontrerai IRL pour la première fois,
  • Pierre Joye (Core Dev PHP, OSS développeur (curl, gd, etc.), Microsoft OSTC), avec qui j’ai longuement discuté lors du PHP Tour à Lyon en juin,
  • Et Julien Pauli (Release Manager de PHP 5.5 et co-RM de PHP 5.6), que je croise régulièrement depuis maintenant plusieurs années.


Comme d’habitude, la liste des conférences est bien fournie.

Au premier coup d’œil, en voici quelques unes qui attirent mon attention et auxquelles il est probable que j’assiste — soit par pure curiosité, soit parce qu’elles pourraient répondre (ou, au moins, fournir des pistes de solutions) à des problématiques que je rencontre fréquemment :

  • PHP dans les distributions RPM : on dit très souvent que l’adoption des nouvelles versions de PHP est freinée par les distributions orientées entreprises, qui ont tendance à rester sur de vieilles versions dites stables. Pour moi qui suis plutôt Debian, je suis curieux de voir comment les choses évoluent à ce niveau côté Redhat.
  • Cohabitation de PHP et Node au Monde, pourquoi et comment : étant souvent en train de jongler entre plusieurs technos en fonction des projets, je suis curieux de voir comment certains problèmes que je rencontre au quotidien ont pu être approchés chez Le Monde.
  • Composer Best Practices : utilisant composer depuis plusieurs années, j’ai parfois l’impression de le subir… Je me dis donc qu’il pourrait être intéressant d’aller écouter son Lead Dev1 !
  • La mesure, ce n’est pas que pour le devops : pour celle-ci, il s’agit principalement de curiosité ;-). J’ai envie de profiter d’un retour d’XP sur le sujet Lean Startup, pour voir en quoi les différences avec une approche plus traditionnelle pourraient être bénéfiques, à la fois pour l’entreprise où je bosse et pour ses clients.
  • Laisse pas traîner ton log ! : avec une grosse dizaine d’applications qui logguent en vrac vers une quantité parfois effrayante de fichiers, j’ai besoin d’une solution qui me permette de les gérer — et surtout, d’en extraire les données importantes ! J’entends parler de stack ELK depuis un moment, sans avoir jusqu’à présent eu le temps de fouiller… Voici l’occasion d’en apprendre plus ;-)
  • Retour d’expérience : tests fonctionnels chez Maisons du Monde : j’ai plusieurs fois vu des batteries de tests fonctionnels, sans que les équipes aient forcément l’impression que ça marchait bien. Je suis donc curieux de voir comment d’autres ont fait et ce que ça leur apporte.
  • VDM, DevOp malgré moi : d’un site perso à des millions de pages vues par jour, ça a dû faire un bon exercice de scalabilité pour une stack PHP. Là où on commence à avoir des solutions assez classiques, ce n’était pas forcément le cas il y a quelques années — j’ai donc envie de voir comment ça s’est passé ici et de comparer avec les approches prises sur des applications sur lesquelles j’ai bossé.

En complément, je ferai peut-être aussi un tour aux conférences suivantes — pas tellement pour ce qu’elles m’apporteraient d’utilisable tout de suite, mais plus parce que j’ai entendu parler des sujets et que j’aimerais en savoir un peu plus, sans pour autant pouvoir y consacrer un week-end ou deux à fouiller par moi-même :

  • An introduction to the Laravel Framework for PHP : quand il s’agit de frameworks, je suis plus symfony… Mais Laravel fait beaucoup parler de lui ces derniers temps (peut-être plus outre-Atlantique qu’ici) ; j’ai donc envie de voir un peu à quoi ça ressemble.
  • Bringing Sculpin to Life : sans forcément être grand fan de générateurs de sites statiques, j’entends de plus en plus souvent parler de Sculpin. Voici donc aussi l’occasion d’en apprendre plus.

Bien sûr, je n’exclue pas la possibilité de changer d’avis au dernier moment avant de rentrer dans une salle… Et de partir vers une autre. Ça ne serait pas tout à fait la première fois ^^


Des ateliers pratiques d’une demi-journée sont organisés en parallèle des conférences.

Je recommande tout particulièrement celui que Julien Pauli va donner sur le développement d’extensions PHP2 : j’ai assisté il y a plusieurs années à une des premières versions de cet atelier et j’en étais ressorti avec plein d’étoiles dans les yeux. Je n’ai donc aucun doute sur le fait qu’il représentera cette année une demi-journée fort instructive pour ceux qui voudraient se lancer dans le sujet !

Pour vous inscrire, c’est par ici. Faites vite, il n’y a que 15 places — et la moitié sont déjà parties !

En fonction de vos préférences, vous pourrez aussi vouloir jeter un coup d’œil aux autres ateliers :


Nous croiserons-nous à ce Forum PHP ?



  1. Cette conférence pourrait compléter la conférence gestion de dépendances et composer qui a eut lieu à Lyon hier soir, qui parlait plus d’industrialisation (j’ai particulièrement été intéressé par le côté Satis pour ne pas dépendre de github). 

  2. Je n’assisterai très probablement pas moi-même à cet atelier : puisque je connais assez bien le sujet, je préfère laisser la place à quelqu’un qui aura plus de choses à découvrir que moi. 

Par Pascal MARTIN le mercredi 10 septembre 2014

Cet article est aussi disponible en français.

I’ve been quite busy in August (and I’ve taken some holidays, during which I pretty much had no Internet access, which doesn’t help), and I haven’t been able to write my digest of internals@ for July 2014 in due time. Instead of writing it now and keeping getting late for August’s one, I’ve chosen to skip my digest of July — and to write August’s one, which you can read below.


August 2014 went back to a reasonable number of 700 messages on PHP’s internals@ mailing-list, after a busy month of July with 1144 mails.

As a graph representing the number of mails per month for the last three years, we’d get:

Johannes Schlüter started this month of August 2014 annoucing the first Release Candidate of PHP 5.3.29. Two weeks later, he announced the release of PHP 5.3.29, which marks the End Of Life of PHP 5.3 : no other new release of PHP 5.3 is planned (which means there won’t be any bug fix anymore — or even security fix).


As PHP 5.3 has reached its End Of Life, Jan Ehrhardt asked what would become of PHP 5.4. According to the Release Process, PHP 5.4, published in March 2012, should have gotten bug-fixes for two years. Still, like Stas Malyshev mentionned, it would be fair for PHP 5.4 to switch to “security fixes only” mode after PHP 5.6 is released — and maintaining two stable (5.4 and 5.5 — or 5.5 and 5.6) releases in parallel should be OK.

A few days later, Stas Malyshev announced that PHP 5.4.33 should be the last version of branch 5.4, except for possible security-fixes.


In the middle of the month, Ferenc Kovacs said the release of PHP 5.6 was getting close. And, a few days later, on August 28th, he announced the release of PHP 5.6.0!

In another thread, he explained why PHP 5.6 was two month late (according to the initial planning): several intermediate versions (alpha, beta, RC) have been released one or two week late, for different reasons — and, in the end, it adds up to two months.


Andrea Faulds noted it might be interesting to have one last 5.x version before the release of PHP 7 — which would mean PHP 5.7. The idea is that, as PHP 7 is a new major version, it will likely require about two years of work before it can be released — and it will include some new major features (and some BC-breaks).

A 5.7 release would facilitate the migration to PHP 7 — typically, by adding deprecation warnings for features that will greatly change. This intermediate version could also act as a fallback if PHP 7 was to be released later than expected. As Ferenc Kovacs pointed out, no minor release has, for now, been released in less than a year, and it seems hard to conceive that a major version (with more changes and more impact) could be released quicker.

Of course, as Derick Rethans, Zeev Suraski and several others answered, it might be better to put more energy into PHP 7, instead of dividing it between two versions. One should not reproduce what happened with PHP 6, where things stopped going forward because each developer wanted to add one more feature.


After the series of performances optimizations known as phpng had been developed on its separate branch for several months, Zeev Suraski opened the votes, at the beginning of the month, on RFC: Move the phpng branch into master, to decide if this branch would be merged to PHP’s master branch.

The matter had been debated a lot before and discussions were, this time, quite short — even if some indicated the changes brought by this branch were important and would have a strong impact.

In the end, this RFC passed, with 47 votes “yes” and 2 votes “no”. As a consequence, the phpng branch has been merged to master.


Andrea Faulds has written two RFCs related to functions and the Closure class:

The first one, which aimed to add a call() method to the Closure class, to allow binding at call-time, hasn’t been discussed much. Votes have been opened in the middle of the month and this RCS passed, with 13 votes “yes” et 0 votes “no”.

More messages have been exchanged about the second one: the idea was to add to PHP a syntax that would allow one to reference functions (in a more explicit way than just using their name as strings). As Stas Malyshev noticed, the proposed syntax might cause conflicts with passing parameters by reference, but the RFC seemed to be of interest for a few people.


Right at the end of July, Nikita Popov wrote the RFC: Abstract syntax tree, suggesting to add an intermediate step to the compilation process of PHP scripts.

This could allow new syntaxes that are currently impossible for technical reasons, might allow to remove a few hacks, and make the compilation of PHP scripts easier to maintain. By the way, the implementation that comes with the RFC already fixes a few syntax quircks (especially about yield and list). This change on the compilation process doesn’t have much impact on the execution of scripts: performances or memory usage will not change. Still, introducing an AST as some impact (10-15% gain for performances, at the cost of some increase in memory consumption) on the compilation phase.

Comment on this RFC have been quite positive and, without much surprise, it passed, with 47 votes “yes” and 0 votes “no”.

As a complement, it should be possible, in the future, to expose this AST to user-space (for static code-analysis, for example) and to provide extensions with some hooking mechanism so they could intervene during the compilation process.


Andrea Faulds wrote the RFC: Integer Semantics, which aims to improve cross-platform consistency for PHP integers by fixing a few cases for which behavior wasn’t clearly defined.

Kris Craig noted the role of a high-level language — such as PHP — should be to hide this kind of differences. Even if they made some sense when most developers were coming from a C-background, it’s less the case today.

Derick Rethans answered one must be extremely careful before breaking compatibility, including for a future major version like PHP 7. Any change that would be difficult to detect will create frustration for end-users and slow down the adoption of that new version. Several developers have confirmed this idea, pointing towards problems shown by Python 2 and 3 or Perl 6. Still, a major version definitely is the right time for improving the language.


Sara Golemon has written the RFC: Make defining multiple default cases in a switch a syntax error which wants to forbid using several default cases in a single switch block (today, only the last default is taken into account). Responses have been quite positives, to remove this odd behavior.

Some suggested a change of this type could have its place in PHP 5.7 — but it would go against the idea of not breaking compatibility between minor versions, which means this fix should find its place in PHP 7. Raising a E_DEPRECATED warning should be possible for PHP 5.7. After a while, Peter Cowburn asked if all this process (RFC, discussion on the mailing-list, votes) wasn’t a bit too much for something that could be considered as no more than a bug.

In parallel, votes had been opened, before some developers noticed the required minimum duration for discussions on a RFC, before opening it to votes, is two weeks. Considering those debates for something that felts like a bug-fix, Sara Golemon dropped the matter. Levi Morrison re-started it a few days later.

Note: the detection of this inconsistency is one of the first results of work started last month on the specification for PHP.


Marc Bennewitz wrote the RFC: Binary String Comparison, which states PHP’s behavior for comparisons is sometimes surprising when dealing with strings, as some type-casting is automatically used (basically, comparisons are non-strict) and proposes to change the behavior of non-strict comparisons for string so they become strict.

Several answers indicated changing this behavior today would cause problems, as it would break a major feature of PHP. In any case, considering some first responses, it doesn’t seem like this RFC is going to have much success.


Right at the beginning of the month, a mailing-list has been created for members of AFUP (French User-Group), to discuss in French about RFCs announced on internals@.

Following the discussions we’ve had on this mailing-list, I have (as I’m acting as its coordinator) posted a summary of AFUP’s members’ opinion on three threads:

Basically, we would like for the community (using a User-Group, to have some official entity) to participate more in the evolution process of PHP. This mailing-list and the resulting mails to internals@ seem to us like a good first step toward that goal.


Votes on RFC: intdiv() have ended: adding a new operator for integer division has been rejected (with 24 votes “no” and 5 votes “yes”) and the alternative solution — adding an intdiv() function — has passed (with 28 votes “yes” and 0 votes “no”).

To help with debugging, Dmitry Stogov suggested to add a new get_resources() function that would return a list of all existing resources (optionally limited to a specific type). This changes has been commited a few days later — no need for an RFC for such a simple thing.

Michael Wallner wrote the RFC: Add pecl_http to core. For now, only a few mails have been exchanged, but Johannes Schlüter noted it might be interesting to use this implementation for internal HTTP(s) stream — and for this extension to systematically (or, at least, by default) be enabled.

After several months of debates, Anatol Belski annouced the 64-bits patch for integers and strings length has (finally) been merged.

Dmitry Stogov set up a new memory manager for PHP 7. The matter has not been discussed much, but it seems this manager brings some performance gain — even it it might be relatively limited.



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.


Par Pascal MARTIN le mercredi 10 septembre 2014 3 commentaires

This post is also available in English.

Ayant eu un mois d’août assez occupé (et je suis parti en vacances sans réelle connexion Internet, ce qui n’aide pas ^^ ), je n’ai pas réussi à rédiger mon dépilage d’internals@ pour Juillet 2014 dans les temps, d’autant plus que juillet a été chargé. Au lieu de rédiger celui-ci maintenant et de continuer à accumuler du retard pour celui d’août, j’ai choisi de sauter le dépilage de Juillet — et donc de passer directement à celui d’août, que voici.


Août 2014 est revenu à un nombre raisonnable de 700 messages sur la mailing-list internals@ de PHP, après un mois de juillet qui avait été animé, avec 1144 mails.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient :

Johannes Schlüter a ouvert ce mois d’août 2014 en annonçant la première Release Candidate de PHP 5.3.29. Et, deux semaines plus tard, il a annoncé la sortie de PHP 5.3.29, qui marque la fin de vie de PHP 5.3 : plus aucune nouvelle version de PHP 5.3 ne devrait être publiée (ce qui signifie aucune correction de bug, ni même de faille de sécurité).


PHP 5.3 ayant atteint sa fin de vie, Jan Ehrhardt a demandé ce qu’il advenait de PHP 5.4. D’après le processus releases, PHP 5.4, sorti en mars 2012, aurait du recevoir des correctifs de bug pendant deux ans. Toutefois, comme l’a souligné Stas Malyshev, il serait raisonnable pour PHP 5.4 de passer en mode “corrections de failles de sécurité uniquement” une fois PHP 5.6 sortie — et il ne serait pas choquant de maintenir deux versions stables (5.4 et 5.5 — ou 5.5 et 5.6) en parallèle.

Quelques jours plus tard, Stas Malyshev a annoncé que PHP 5.4.33 devrait être la dernière version issue de la branche 5.4, sauf correction de failles de sécurité.


En parallèle, en milieu de mois, Ferenc Kovacs a annoncé que la sortie de PHP 5.6 approchait. Et quelques jours plus tard, le 28 août, il a annoncé la sortie de PHP 5.6.0 !

Dans un autre fil de discussion, il a expliqué pourquoi PHP 5.6 était sortie deux mois en retard par rapport au planning initial : plusieurs versions intermédiaires (alpha, beta, RC) ont, pour différentes raisons, pris une ou deux semaines de retard — et le tout cumulé mène à deux mois.


Andrea Faulds a souligné qu’il pourrait être intéressant d’avoir une dernière version 5.x avant la sortie de PHP 7 — ce qui mènerait à PHP 5.7. En effet, PHP 7 étant une nouvelle version majeure, il semblerait probable qu’il faille environ deux ans avant de pouvoir la sortir et elle inclura de nouveaux points majeurs (et quelques cassures de compatibilité).

Une version 5.7 permettrait de faciliter la migration vers PHP 7, typiquement en ajoutant des avertissements d’obsolescence pour les fonctionnalités qui seront profondément modifiées. Cette version intermédiaire pourrait aussi jouer le rôle de solution de repli si PHP 7 venait à être repoussée pour une raison ou une autre. Comme l’a noté Ferenc Kovacs, aucune version mineure n’a pour l’instant été réalisée en moins de un an et il semble difficile d’imaginer qu’une version majeure (incluant plus de changements ayant plus d’impact) puisse être publiée plus rapidement.

Bien sûr, comme l’ont fait remarquer Derick Rethans, Zeev Suraski et plusieurs autres, il pourrait être préférable de consacrer plus d’énergie à PHP 7, plutôt que de diviser l’effort entre deux futures versions. Il ne faudrait pas non plus reproduire ce qui s’est passé avec PHP 6, où les choses ont fini par cesser d’avancer parce que chacun voulait ajouter encore une fonctionnalité.


Alors que la série d’optimisations orientées performances connues sous le nom de phpng était développée sur une branche distincte depuis maintenant plusieurs mois, Zeev Suraski a ouvert les votes, en début de mois, sur la RFC: Move the phpng branch into master, pour déterminer si cette branche allait être mergée vers la branche master de PHP.

Le sujet ayant déjà été (longuement) débattu, la discussion a été cette fois-ci assez brève — même si plusieurs ont souligné que les modifications apportées par cette branche étaient importantes et auraient un impact fort.

Au final, la RFC a été acceptée, avec 47 votes “pour” et 2 votes “contre” : la branche phpng a donc été mergée vers master.


Andrea Faulds a annoncé l’ouverture de deux RFCs en rapport avec les fonctions et la classe Closure :

La première, qui proposait d’ajouter une méthode call() à la classe Closure, permettant de binder à l’appel, n’a pas tellement été discutée. Elle a été ouverte aux votes en milieu de mois et a été acceptée, avec 13 votes “pour” et 0 vote “contre”.

La seconde a généré plus d’échanges : elle proposait d’ajouter à PHP une syntaxe permettant de faire référence à des fonctions (autrement que par leur nom sous forme d’une chaîne de caractères). Comme l’a souligné Stas Malyshev, la syntaxe proposée entre potentiellement en conflit avec le passage par référence, mais l’idée a semblé en intéresser plus d’un.


À la toute fin juillet, Nikita Popov a rédigé la RFC: Abstract syntax tree, qui proposait de mettre en place une structure intermédiaire dans le processus de compilation des scripts PHP.

Cela pourrait permettre de nouvelles syntaxes techniquement impossibles aujourd’hui avec une compilation en une seule passe, et permettrait de supprimer quelques hacks ainsi que de rendre l’implémentation plus claire et plus facile à maintenir. D’ailleurs, l’implémentation proposée corrige déjà certains points de syntaxe (notamment sur yield et list). Cette modification sur la compilation n’a globalement pas d’impact sur l’exécution : les performances ou l’occupation mémoire ne changeront pas. Par contre, l’introduction d’un AST a un impact (amélioration de 10-15% pour les perfs, mais augmentation de la mémoire consommée) sur la compilation.

L’idée a été fort bien reçue et, sans surprise, cette RFC est passée, avec 47 votes “pour” et 0 vote “contre”.

En complément, il pourrait être possible à l’avenir d’exposer l’AST à l’espace utilisateur (pour de l’analyse statique de code, par exemple), ainsi que de permettre à des extensions de se brancher dessus pour intervenir lors de la compilation.


Andrea Faulds a rédigé la RFC: Integer Semantics, qui propose d’améliorer la consistance cross-plateformes des entiers PHP en corrigeant quelques cas dont le comportement n’était pas clairement défini.

Comme l’a fait remarquer Kris Craig, le rôle d’un langage de haut niveau — comme PHP — serait effectivement de masquer les différences de ce type. En effet, même si ces elles avaient un sens lorsque nombre de développeurs venaient du langage C, c’est nettement moins le cas aujourd’hui.

Derick Rethans a rebondi sur le sujet, en notant qu’il fallait être extrêmement prudent avant de casser la compatibilité, y compris pour une future version majeure comme PHP 7. En effet, tout changement qui serait difficile à détecter entraînera de la frustration pour les utilisateurs et freinera l’adoption de cette nouvelle version. Plusieurs intervenants ont confirmé cette pensée, faisant notamment référence aux problèmes de Python 2 et 3 ou à Perl 6. En même temps, une version majeure est définitivement l’occasion d’améliorer le langage.


Sara Golemon a rédigé la RFC: Make defining multiple default cases in a switch a syntax error qui proposait d’interdire l’écriture de plusieurs cas default au sein d’un même bloc switch (en pratique, aujourd’hui, seul le dernier default est pris en compte). Les retours ont été plutôt positifs pour supprimer ce comportement aberrant.

Certains ont suggéré qu’un changement de ce type pourrait être mis en place pour PHP 5.7 — mais ce serait violer le principe qui interdit les cassures de compatibilité sur des versions mineures et ce changement aurait donc plus sa place pour PHP 7, quitte à générer une E_DEPRECATED en 5.7. Au final, Peter Cowburn a demandé si tout ce processus (RFC, discussion sur la mailing-list, votes) n’était pas un peu lourd pour quelque chose qui pourrait être considéré comme n’étant qu’un bug.

Entre temps, les votes avaient été ouverts, avant que plusieurs intervenants ne fassent remarquer que la durée minimale de discussions sur une RFC, avant ouverture des votes, est de deux semaines. Face à ces débats pour ce qui lui semblait n’être qu’une simple correction de bug, Sara Golemon a laissé tomber le sujet. Levi Morrison a repris le sujet en main quelques jours plus tard.

Il est à noter que la détection de cette incohérence fait suite au travail commencé le mois précédent autour d’une spécification pour le langage PHP.


Marc Bennewitz a rédigé la RFC: Binary String Comparison, qui part du constat que le comportement des comparaisons de PHP est parfois surprenant lorsque l’on compare des chaînes de caractères, puisqu’un transtypage est automatiquement appliqué (en somme, la comparaison est non-stricte) et propose donc de modifier le comportement des comparaisons “non-strictes” de chaînes de caractères afin de les rendre strictes.

Bon nombre de retours ont indiqué que modifier ce comportement serait problématique aujourd’hui, puisque cela casserait une fonctionnalité majeure de PHP. Quoi qu’il en soit, considérant les premiers retours, cette RFC ne semble pas vraiment bien partie.


Au tout début du mois, une mailing-list a été mise en place pour les membres de l’AFUP, en vue d’échanger en français sur les propositions annoncées sur internals@.

Suite aux discussions que nous avons eu sur cette mailing-list, j’ai (en tant que coordinateur de celle-ci) posté l’avis de l’AFUP sur trois sujets :

Le souhait que nous avons est d’essayer d’impliquer plus la commauté (par le biais d’un user-group, pour donner un sens officiel) au processus d’évolution du langage. Cette mailing-list et les mails vers internals@ qui en résultent nous semblent constituer un bon premier pas.


Les votes sur la RFC: intdiv() se sont terminés : l’ajout d’un nouvel opérateur de division entière a été rejeté (par 24 “contre” et 5 “pour”) et la solution de repli — l’ajout d’une fonction intdiv()a été acceptée (avec 28 votes “pour” et 0 vote “contre”).

Pour faciliter le debuggage, Dmitry Stogov a proposé d’ajouter une nouvelle fonction get_resources() qui retournerait la liste de toutes les ressources existantes (en se limitant éventuellement à un type donné). Cette modification a été réalisée quelques jours plus tard — pas besoin d’une RFC pour un ajout simple et précis comme celui-ci.

Michael Wallner a rédigé la RFC: Add pecl_http to core. Pour l’instant, peu de retours sont arrivés, mais Johannes Schlüter a noté qu’il serait intéressant d’uniformiser en utilisant cette implémentation pour les flux HTTP(s) internes et que cette extension soit systématiquement (ou, au moins par défaut) activée.

Après de longs mois, Anatol Belski a annoncé que le patch 64-bits pour les entiers et les longueurs de chaînes de caractères avait (enfin) été mergé.

Dmitry Stogov a mis en place un nouveau gestionnaire de mémoire pour PHP 7. Le sujet n’a que peu été discuté, mais ce gestionnaire semble apporter un gain de performances — même s’il ne serait que relativement faible.



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.


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 jeudi 4 septembre 2014 9 commentaires

Quand j’étais plus jeune et/ou étudiant, je n’avais pas tellement l’habitude de boire de café : j’en prenais un de temps en temps, sans plus — et ce n’était nullement une habitude.

Le jour de mon arrivée en SSII1, je ne m’étais quasiment pas encore installé qu’un de mes collègues me lançait un “tu prends un café ?”. Considérant que la machine à café était un moyen parfait pour faire connaissance avec les collègues2, j’ai accepté. Pareil pour les autres collègues avec qui j’ai eu l’occasion de prendre un café les jours suivants. Ou même pour les nouveaux arrivants que j’ai accueillis par la suite, d’ailleurs.

Quelques mois après la fin de mon stage et une fois embauché, gros projet dont la livraison approchait et horaires tout à fait peu raisonnables aidant, j’étais encore en train de dépiler des tickets en me disant “allez, dernier café”, à plus de 21h


J’en suis rapidement arrivé à avoir une consommation habituelle tournant de 6 à 8 cafés par jour — il suffit de compter :

  1. Un premier café le matin après m’être réveillé, chez moi, en dépilant mes RSS.
  2. Un café en arrivant au boulot vers 8-9h selon les jours, soit en dépilant les mails (alertes, crons, rapports d’erreurs, …) de la nuit, soit en faisant une pause café à discuter avec les autres collègues matinaux3.
  3. Un café en milieu de matinée, aux environs de 10h.
  4. Un autre en fin de matinée, vers 11h45, avant la pause midi.
  5. Encore un juste avant 14h, avant de ré-attaquer pour l’après-midi,
  6. Un autre en milieu d’après-midi, aux environs de 16h — assez souvent, celui-là était l’occasion d’une pause café passée avec un collègue, à discuter d’un point technique précis du projet sur lequel nous étions en train de bosser4.
  7. Et enfin, un petit dernier vers 17h30 avant de finir la journée.

Ça va vite : en comptant les points ci-dessus, j’en suis déjà à 7. Et c’était pour un jour normal : avec des horaires débordant plus tôt le matin et plus tard le soir les jours de rush, il m’arrivait d’ajouter un ou deux café(s) de plus

En y repensant, à raison d’une trentaine de centimes par café (pour les années où on avait un distributeur de café au bureau, notamment) six ou plus fois par jour, ça fait déjà de l’ordre de 2€ par jour. Ça fait un budget café tournant aux environs de 400€ par an ! Et ce sans compter le prix de celui du matin bu chez moi !


A ceux qui, occassionnellement, me disaient “tu bois trop de café”, je répondais que “mais non” : après tout, je ne dormais pas si mal et j’étais à peu près en pleine forme la journée (ou alors, je considérais que c’était juste parce que “je bossais trop”).

D’un autre côté, quasiment tous les week-end, j’étais bien fatigué, et il m’arrivait d’avoir mal au crâne, surtout le dimanche… Même chose pour les vacances, où j’avais régulièrement l’impression d’être épuisé, même en dormant bien plus longtemps que les jours de travail…

Un peu par hasard (merci Twitter), je suis tombé l’an dernier sur un article qui expliquait dans les grandes lignes comment marchait le café au niveau du cerveau5 et j’ai réalisé que la fatigue et les maux de tête les week-end pouvaient peut-être venir d’un manque de café, puisque je ne prenais que rarement de café le week-end.


Du coup, un lundi matin l’été dernier, j’ai arrêté le café. Enfin, j’ai essayé : à 11h j’étais déjà en train d’en prendre un ;-(

Le lendemain, mardi, second essai. Nettement plus réussi. Par contre, j’ai été un peu fatigué toute la journée. C’était à prévoir…

Mercredi matin en partant au boulot, debout dans le métro qui bougeait, j’ai eu l’impression que j’allais tomber tellement j’étais épuisé. Pourtant, la veille au soir, je m’étais couché tôt, puisque je me sentais fatigué, et j’avais fait une nuit plutôt longue !

Je me souviens d’un truc urgent / critique / important / … qui m’est tombé dessus ce même mercredi au boulot en fin d’après-midi : la première pensée qui m’est venue à l’esprit, c’est “il me faut un café, rrrhhhaaaa un café il me faut un café, du café, j’ai besoin d’un café !!!”.

Finalement, j’ai passé toute la semaine en ayant l’impression d’être fatigué6, en dormant beaucoup pour compenser et en prenant des dolipranes les uns après les autres pour lutter contre le mal de tête qui ne voulait pas partir. Il m’a fallu attendre samedi pour que ça commence à aller mieux, et dimanche après-midi pour que ça aille enfin bien.

Le titre de cet article vient de là : j’ai un peu eu le sentiment de survivre à cette semaine sans café !

En même temps, j’ai fait ça brutalement, en passant de 6-8 cafés par jour à 0, ce qui peut expliquer les symptômes — mais, au risque de me faire traiter de binaire, je trouve que c’est plus facile que de diminuer petit à petit. Cette semaine et la suivante, je faisais des pauses eau avec les collègues qui prenaient leur pause café :-D

La seconde semaine sans café, tout allait bien.

Et donc, forcément, j’ai repris — à raison d’un le matin en me levant, un second à 9h30 après le stand-up meeting et un troisième en début d’après-midi. Je me console en me disant que c’était plus raisonnable qu’avant !


Au bout de quelques mois, cette année, j’ai un peu retrouvé l’impression d’être fatigué les week-ends, avec d’occasionnels maux de tête le dimanche. Moins que l’année dernière, mais ça y ressemblait quand même.

Donc, au printemps, j’ai à nouveau arrêté. J’ai eu mal au crâne pendant quelques jours, mais moins que l’an dernier — parce que ce n’était pas la première fois que j’arrêtais ? Ou parce que je prenais moins de café par jour que la fois précédente ?

Maintenant, j’en suis à pas loin de quatre mois sans café. Et, surtout, je n’ai plus besoin de café, y compris lorsqu’il s’agit de réaliser une grosse mise en production à 4h du matin au boulot ou de faire 10h de trajet pour partir en vacances \o/.7

Reste à voir si je serai capable d’en prendre de temps en temps, purement parce que j’en ai envie8… sans pour autant rechuter !


  1. J’ai réalisé mon stage de fin d’études en SSII en 2006 et j’y suis resté plus de cinq ans ensuite. 

  2. Après tout, il me semblait important de connaître un minimum les collègues avec qui j’allais bosser. En sortant d’école, je me disais que parler autour d’un café était un moyen de se mettre dans le projet sans tout de suite attaquer en mode allez voila le code, bon courage. Je continue d’ailleurs à le penser aujourd’hui, probablement encore plus qu’à l’époque, d’ailleurs. 

  3. La pause café d’avant 9h, je ne me suis jamais senti coupable de la faire durer un peu : même en prenant mon temps, j’étais à mon poste avant l’heure officielle d’embauche. 

  4. La pause café de l’après-midi, loin des postes de travail, ça permet de sortir un peu le nez du guidon et de réfléchir, souvent à deux ou trois, de manière un peu plus posée — ça a souvent été l’occasion de débloquer des problèmes ! 

  5. Je n’ai plus le lien et ne parviens pas à le retrouver. Mais ça parlait de trucs chimiques dans le café qui se mettent à la place d’autres trucs chimiques dans des récepteurs de trucs chimiques liés à la fatigue et/ou au sommeil dans le cerveau, et que ça expliquait que le café donne un coup de boost anti-fatigue/sommeil. Forcément, en arrêtant le café, les trucs chimiques normaux reviennent dans les récepteurs que le café bloquait, provoquant l’impression de fatigue. (Désolé pour les trucs chimiques, la lecture de l’article date un peu ; et les années où les molécules étaient pour moi plus que des trucs chimiques remontent à loin ^^). Merci @tut_tuuut pour le lien vers la vidéo Your Brain On Coffee qui explique à peu près la même chose de manière simple et rapide ! 

  6. Je dis que j’avais l’impression d’être fatigué parce que je faisais de longues nuits et dormais donc suffisamment pour que mon corps soit en forme. Je ressentais la fatigue, mais je n’avais pas en parallèle le sentiment d’être moins efficace dans mon travail (j’étais par contre peut-être un peu plus ronchon ?) 

  7. Et au passage, en comptant les cafés chez moi et ceux au bureau, ça me fait dans les 450€ d’économies par an ! 

  8. Quand il ne s’agit pas d’en prendre 6-8 par jour, j’apprécie le goût du café et le fait de boire un truc chaud (surtout l’hiver, le matin). Donc, j’ai reprendrai certainement un jour ou l’autre : après tout, pourquoi pas ?