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

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, 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 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 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 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). 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://

  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, 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, 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 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 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). 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://

  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, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon

Par Pascal MARTIN le mardi 6 mai 2014 5 commentaires

This post is also available in English.

Le mois d’avril 2014 qui vient de se terminer a vu 355 messages sur la mailing-list internals@ de PHP — ce qui en fait un mois très calme, avec pas loin de moitié moins d’échanges qu’en mars.

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 tendance à la baisse du volume d’échanges, déjà entamée le mois dernier, se confirme : PHP 5.6 est en pleine phase de bêta — et donc, plus aucune fonctionnalité ne peut y être ajoutée. Les discussions se sont donc un peu calmées ; et elles ne sont pas encore complètement lancées sur la version suivante.

Le 10 avril, Ferenc Kovacs a annoncé que PHP 5.6.0beta1 avait été taggée — et elle a été publiée le lendemain !

Ce passage en phase de versions bêta marque le feature-freeze de PHP 5.6 : plus aucune nouvelle fonctionnalité ne peut désormais être ajoutée pour cette version.

En parallèle du passage de PHP 5.6 en phase de bêta, Julien Pauli a dressé une liste des points sur lesquels il estimait que la majorité était d’accord, pour la prochaine version majeure de PHP :

  • une prochaine version majeure de PHP devrait être publiée ; aussi rapidement que possible,
  • elle devrait être nommée “PHP 6”,
  • lorsque c’est nécessaire, la compatibilité antérieure pourra être cassée, et cette version pourra introduire de nouvelles notions,
  • la principale notion sur laquelle il faut se concentrer est Unicode,
  • les idées évoquées jusqu’à présent ont été regroupés sur,
  • et le développement se ferait par le biais d’une itération de deux ans.

Les prochaines étapes seraient alors :

  • de commencer à rédiger des RFCs ciblées pour PHP 6 et d’échanger sur les idées correspondantes,
  • ainsi que de créer la branche Git pour PHP 6.

Kris Craig a rapidement indiqué qu’il serait intéressant de passer à un workflow Git plus organisé que ce qui se fait actuellement. Son mail a été suivi d’une discussion sur ce qui se faisait actuellement, ainsi que sur le rôle des Release Managers par rapport aux fonctionnalités et à leur merge.

Alternativement, comme souligné par Nikita Popov, la branche master pourrait simplement jouer le rôle de prochaine version majeure, en ne créant une nouvelle branche de version que lorsque la release approchera.

En parallèle, Johannes Schlüter a suggéré qu’il serait intéressant de mettre en place un principe de merge des branches de release vers leurs branches parentes — sans que l’idée ne semble convaincre.

Eli a ensuite remis une couche sur la question du numéro que cette prochaine version devrait porter, en relatant le résultats de conversations qu’il a eu plusieurs fois avec des membres de la communauté.

D’après lui, ne devrait pas s’appeler “PHP 6” : il existe trop de ressources parlant de “PHP 6” tel qu’il était pensé il y a cinq ans de cela — et retenir ce numéro de version serait source de confusion (il existe des livres — papier — sur “PHP 6”, par exemple ! Sans compter la quantité d’articles publiés sur le sujet1, de slides de présentations données ici et là2, …). Il ne faut pas oublier que la grande majorité des développeurs utilisant PHP ne fait pas partie de la communauté et ne sont donc pas toujours au courant de l’actualité.

Passer directement à “PHP 7” pourrait être une solution acceptable à ce “problème”, et ne devrait pas tellement nuire en terme d’image : “PHP 6”, aujourd’hui, serait déjà considérée comme une expérience ratée.

Bien sûr, tout le monde n’est pas d’accord avec cette proposition. Après tout, “PHP 6” n’a jamais été diffusée et s’est arrêtée à une branche de développement ! De plus, la communication entourant la sortie de la prochaine version majeure de PHP devrait rapidement recouvrir et masquer le plus gros de ce que l’on peut aujourd’hui encore trouver sur l’ancien PHP 6.

Et, en même temps, comme l’a souligné Trevor Suarez, il faudrait peut-être commencer à la coder, cette future version ; et le nom pourrait n’être choisi que lorsque la release approchera ^^

Stas Malyshev a essayé d’attirer l’attention sur le fait que les tests de PHP sur Travis CI ne restent jamais au vert bien longtemps — au point que l’état normal soit les tests échouent.

Une première étape, avant de corriger cela, serait d’accepter comme objectif, pour l’équipe de développeurs de PHP, que les tests doivent rester au vert. Ensuite, envoyer un mail à celui qui a cassé le build pourrait aider (la suite de tests de PHP est longue — et chaque développeur ne la relance pas en entier sur son poste à chaque commit).

Dans la suite de cette réflexion et en vue de la formaliser, Stas Malyshev a rédigé la RFC: Keeping PHPT Tests Green. Ferenc Kovacs a profité de la discussion pour proposer d’étendre la configuration Travis en vue de tester plus de points (plus d’extensions, plusieurs configurations de build de PHP, …). Bien sûr, idéalement, tout changement devrait être effectué via une branche, et les tests devraient être au vert sur celle-ci avant qu’elle ne soit mergée.

Les votes n’étaient pas terminés fin avril, mais les choses semblent aller dans le bon sens, avec une immense majorité de “pour”. Que faire en cas de test qui échoue est une question pour laquelle la réponse semble moins évidente — et il se pourrait qu’elle ne soit pour l’instant pas gravée dans le marbre et laissée à l’appréciation des RMs au cas par cas.

Levi Morrison a annoncé la RFC: Return Type Declarations, dont l’idée est de permettre, lors de la déclaration d’une fonction ou méthode, d’indiquer quel type de donnée elle doit retourner. Par exemple :

function foo(): array {
    return [];

Ce n’est pas la première fois que cette idée est évoquée — et la RFC indique en quoi cette proposition est différente des précédentes.

Les premiers retours ont été plutôt positifs, d’autant que la RFC est bien ciblée et répond à un besoin plusieurs fois exprimé. De plus, cette proposition aiderait aussi au niveau du PHP-FIG, puisqu’il deviendrait possible de type-hinter aussi bien les retours que les paramètres des interfaces qu’il définit.

PHP 5.6 ayant atteint son feature-freeze, cette RFC cible PHP 5.7 ou PHP 6. Je suis curieux de voir comment les choses évolueront — mais au vu des échanges, l’idée me semble plutôt bien partie !

Leigh a demandé ce que les autres développeurs pensaient de l’idée de reconnaître des positions négatives dans des chaînes de caractères, pour obtenir des caractères à partir de la fin de celle-ci ; par exemple :

$string = 'foobar';
print $string[-1]; // prints 'r';
print $string[-2]; // prints 'a';

Les premiers retours ont été plutôt positifs, même si le fait d’utiliser la même syntaxe pour des tableaux et des chaînes de caractères peut être source de confusion pour l’utilisateur.

Bien sûr, cette proposition serait plus intéressante s’il était possible de spécifier un intervalle de positions, et plus la seule position d’un unique caractère :

"foobarbazbuz"[4:7] => "barbazb"
"foobarbazbuz"[4-7] => "barb"
"foobarbazbuz"[4,7] => ["b", "b"] 

Au final, en poussant un peu l’idée, on arriverait à ce que peut permettre Python ;-). Idée qui ne semble pas convenir à tous.

Le mois dernier, Jakub Zelenka avait commencé à travailler sur pecl/jsond, une nouvelle implémentation de parser JSON pour PHP. Il reste encore pas mal de tests à mettre en place et PHP 5.6 est passée en feature-freeze, donc l’intégration de cette nouveauté pourrait être ciblée vers PHP 5.7.

Timm Friebe a rédigé la RFC: Catchable “call to a member function of a non-object”, qui vise à obtenir une erreur non-fatale E_RECOVERABLE_ERROR lors d’une tentative d’appel sur autre chose qu’un objet — sur NULL, typiquement.

Rowan Collins a lancé une discussion autour de la gestion d’erreurs et d’exceptions de PHP, qui gagnerait à être revue pour PHP 6 (un changement de version majeure serait effectivement une bonne occasion). La discussion a beaucoup tourné autour de l’opérateur @ ; et sur le fait que les erreurs de PHP couvrent aujourd’hui de nombreux cas d’utilisation. 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://

  1. Oh, je parlais un peu de (ce qui aurait dû être) PHP 6 à la fin de ma série sur PHP 5.3, en Novembre 2008

  2. Je me souviens d’une des toutes premières présentations organisée par l’AFUP à Lyon à laquelle j’ai assisté, il y a des années de ça : un des deux sujets était “PHP 5.3 et PHP 6” — et suite à celle-ci, j’en avais fait une même du même type au boulot, pour les collègues “non membres de la communauté”. J’en parlais d’ailleurs ici-même en 2008