Par Pascal MARTIN le mardi 23 septembre 2014 3 commentaires

Je suis parti quelques jours en vacances en famille cet été et, le soir, au lieu de regarder la télévision1, j’ai eu tendance à passer un peu de temps devant mon PC, principalement pour rédiger quelques articles2 qui ont été — ou seront — publiés sur ce blog3.

Sans surprise puisque cela m’arrive régulièrement depuis une dizaine d’années, il m’a été demandé si “je travaillais”4. C’est une question qui revient assez fréquemment5 et j’y suis désormais habitué, mais il ne me semble pas avoir déjà écrit sur le sujet6.


Alors, pour mettre les choses au clair : non, quand je suis devant mon PC chez moi (ou en vacances), je ne suis généralement pas en train de travailler au sens usuel du terme.

Au contraire, depuis le tout début de ma carrière, j’ai limité au maximum le fait de ramener du boulot à la maison — quitte à pour cela parfois faire des horaires tout à fait dé-raisonnables (voire contre-productifs7), comme ça m’est plusieurs fois arrivé dans le passé. En particulier, je tâche de ne pas bosser sur “les projets du boulot” lorsque je suis chez moi.


Mais cela ne m’empêche aucunement de pratiquer une activité de veille, y compris, occasionnellement, sur des projets que j’espère pouvoir introduire ensuite au bureau !

C’est aussi sur ce temps que je passe chez moi que j’écris des articles de blog, un livre sur le développement d’extensions PHP, que je me tiens à jour sur des points ayant ou non un lien avec mon activité professionnelle, ou même que je prépare mes sujets et répète pour des conférences.

Certaines fois, lorsque je suis face à une réaction “mais pourquoi tu fais ça ?” ou “mais tu travailles trop !” quand j’explique avoir consacré une partie d’un week-end à une de ces activités, je me demande quelle aurait été la réaction si j’avais annoncé écrire un roman — plutôt qu’un article de blog ou un chapitre d’un livre technique


J’ai la chance d’exercer un métier dans un domaine passionnant8, extrêmement vaste et en perpétuelle évolution — bien assez pour que j’y consacre, avec plaisir, du temps en dehors des quelques dizaines d’heures hebdomadaires que représentent mon travail !

Alors, quand TF1 vend votre temps de cerveau à Coca-cola, laissez-moi consacrer le mien à mon enrichissement ;-)



  1. Entre les infos qui racontent éternellement la même bouillie, les séries américaines à la traduction et aux voix désastreuses, les films qui datent d’il y a des années et sont coupés par des publicités, les jeux stupides et les émissions de TV-pseudo-réalité, … je ne regrette définitivement pas de ne pas avoir de TV chez moi ! 

  2. J’ai par exemple profité de ces quelques jours de vacances pour (enfin !) rédiger l’article Développeur, j’ai survécu deux semaines sans café !, que j’avais à l’esprit depuis un peu plus d’un an ! 

  3. Ayant loué quelque chose comme l’avant-dernière maison la plus éloignée du centre-village, je n’avais pas de connexion internet à disposition (le téléphone recevait à peine ; et je n’avais même pas une connexion Edge stable). Je me suis donc rabattu sur l’écriture d’articles ne demandant pas trop de travaux de recherche (contrairement à d’autres sujets sur lesquels j’avais espérer pouvoir me pencher un peu plus pendant ces vacances). 

  4. Assez étrangement, on ne me demande jamais si je travaille lorsque je suis dans le canapé ou sur une chaise longue en train de lire… Même s’il s’agit d’un livre technique… 

  5. La question “mais tu as travaillé toute la journée ?” revient assez fréquemment lors de conversions téléphoniques, après que j’ai passé un samedi après-midi à coder ou à écrire. 

  6. Alors que j’ai déjà écrit un article allant dans l’autre sens : Non, c’est mon métier ! 

  7. Les horaires contre-productifs, ce n’est qu’après plusieurs années que j’ai réalisé que bosser 14h par jour pendant plusieurs semaines en périodes de rush ne faisait pas vraiment gagner de temps au projet : entre bosser efficacement 8h par jour et être crevé 14h par jour en ayant le sentiment de travailler trop (au détriment de tout ce qui n’est pas travail), le second choix n’est pas le meilleur ! 

  8. C’est un peu comme ça que j’en suis arrivé à faire des études en informatique après le BAC : n’ayant pas trop d’idée quant à mon avenir, j’ai commencé des études en lien avec un truc qui me plaisait — la programmation (et déjà à cette époque, je pratiquais beaucoup en dehors des heures de lycée — faute de métier. Et je m’amusais nettement plus sur les soirées que pendant la journée !). Par la suite, j’ai eu la chance que ça continue à me plaire une fois arrivé dans la vie professionnelle ^^ 

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 ?