131 posts taggués « php »

Par Pascal MARTIN le mardi 1 juillet 2014 1 commentaire

Cet article est aussi disponible en français.

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

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

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

Number of mails on internals@ these last three years

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

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

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

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

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

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

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

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

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

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

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

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

echo $tableau:>clef3:>sub2;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Par Pascal MARTIN le mardi 1 juillet 2014 1 commentaire

This post is also available in English.

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

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

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

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

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

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

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

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

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

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

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

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

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

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

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

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

echo $tableau:>clef3:>sub2;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.

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

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

Par Pascal MARTIN le mercredi 25 juin 2014 1 commentaire

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

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

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

Par Pascal MARTIN le mercredi 25 juin 2014 2 commentaires

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

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

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

Par Pascal MARTIN le jeudi 5 juin 2014

Cet article est aussi disponible en français.

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

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

Number of mails on internals@ these last three years

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Par Pascal MARTIN le jeudi 5 juin 2014

This post is also available in English.

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

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.

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

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

Par Pascal MARTIN le lundi 2 juin 2014 1 commentaire

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

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

Puisque le sujet a été abordé après la présentation, je profite de ce post pour rappeler que je publie tous les mois, sur ce blog, une synthèse de la mailing-list internals@ — la mailing-list des développeurs de PHP ; les articles correspondant sont taggés @internals.

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

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.

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

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

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 https://wiki.php.net/ideas/php6,
  • 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, PHP.next 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.

internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.

  1. 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

Par Pascal MARTIN le mardi 6 mai 2014

Cet article est aussi disponible en français.

This month of April 2014 has seen 355 messages on PHP’s internals@ mailing-list — which means it’s been a calm month, with about only half the number of mails of March.

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

Number of mails on internals@ these last three years

The decrease in the number of mails, already started last month, is confirmed: PHP 5.6 is in full beta-stage — which means that no new feature can be added anymore. As a consequence, discussions have settled down a bit, and have not really begun about the next version yet.

On April 10th, Ferenc Kovacs announced that PHP 5.6.0beta1 had been tagged — and it’s been released the day after!

This transition to beta stage marks the feature-freeze of PHP 5.6: new features cannot be added to this version anymore.

In parallel to PHP 5.6 entering beta stage, Julien Pauli created a list of points on which he thinks the majority of developers agree, for the next major version of PHP:

  • a new major release of PHP should be published; as soon as possible,
  • it should be named “PHP 6”,
  • when necessary, backward compatibility can be broken, and this version can introduce new concepts,
  • the main concept to concentrate on for now is Unicode,
  • ideas talked about up until now have been regrouped on https://wiki.php.net/ideas/php6,
  • and development should be done in a two-years iteration.

The following steps would be:

  • to begin writing RFCs targetting PHP 6 and discuss the corresponding ideas,
  • and to create the PHP 6 Git branch.

Kris Craig noted switching to a more organized git workflow than what’s currently done would be interesting. His mail has been followed by a discussion about what’s being done now, as well as on the role of Release Managers when it comes to features and their merge.

Another idea, as suggested by Nikita Popov, would be to use the master branch to play this role of next major version, and to only create the new version branch when the release gets closer.

At the same time, Johannes Schlüter wrote that it might be interesting to merge release branches to their parents — but the idea didn’t seem convincing.

Eli later came back on the question of what number should be used for this future version, telling about results of conversations he had several times with members of the community.

In his opinion, PHP.next should not be called “PHP 6”: too many resources exist about “PHP 6” as it was thought of five years ago — and keeping this version number would cause a lot of confusion (there are books — dead leaves ones — about “PHP 6”, for example! And there are many articles on the matter, as well as slides of presentations given here and there, …). We should not forget that a vast majority of developers using PHP are not part of the community and don’t always keep track of what happens on the front lines.

Going straight to “PHP 7” might be an acceptable solution to this “problem”, and should not really give a bad image: “PHP 6”, today, would already be considered as a failed experiment.

Of course, not everybody agrees with this proposal. After all, “PHP 6” has never been released and stopped when it still was a development branch! In addition, communication covering the release of the next major PHP version should quickly cover and hide most of the stuff we can yet find about the old PHP 6.

Still, as Trevor Suarez noted, we should maybe begin by coding this future version; its name might be decided later, when the release gets closer ^^

Stas Malyshev tried to get some attention on the fact that PHP tests on Travis CI never stay green for long — to the point the normal state is for tests to fail.

A first step to fix this would to accept as a goal, for the PHP developers team, that tests must stay green. Then, sending a mail to the one who broke the build might help (the PHP tests suite is long — and developers don’t always re-launch it on their computers before each commit).

Following the thought and trying to formalize it a bit, Stas Malyshev wrote the RFC: Keeping PHPT Tests Green. Ferenc Kovacs added it could be interesting to use a wider configuration for Travis in order to test more things (more extensions, several PHP build configurations, …). Of course, ideally, all changes should be done on branches, and tests should be green before those get merged.

Votes were not finished at the end of April, but things did seem to go in the right way, with a large majority of “yes”. The answer seems less obvious when it comes to deciding what should be done when tests fail — the decision might not get written in stone, and could be taken by the RMs on a case by case basis.

Levi Morrison announced the RFC: Return Type Declarations, which would allow developers, when writing the declaration of a function or a method, to indicate what type of data it must return. For example:

function foo(): array {
    return [];

It’s not the first time such an idea is discussed — and the RFC shows in what way this proposal is different from the previous ones.

The first posts have been quite positive, especially as the RFC has a well defined perimeter and answers a need that’s been expressed many times in the past. In addition, this proposal would also be helpful for the PHP-FIG, as type-hinting would become possible for both return and parameters types on interfaces it defines.

As PHP 5.6 has reached its feature-freeze, this RFC targets PHP 5.7 or PHP 6. I’m curious to seen how things will evolve — but, considering the first discussions, they seem to be going the right way!

Leigh asked what other developers thought about the idea of accepting negative offsets for positions in strings, to extract characters from their end; for example:

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

The first comments seemed quite positive, even if using the same syntax for arrays and strings can cause some confusion for users.

Of course, this proposal might be more interesting if it was possible to specify an interval, and not just the offset of a character:

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

In the end, going a bit further, we would arrive to what Python accepts ;-). That idea doesn’t seem to be good for everyone.

Last month, Jakub Zelenka has begun working pecl/jsond, a new JSON parser implementation for PHP. There are still many tests to write and PHP 5.6 is now feature-frozen, so this new parser might arrive with PHP 5.7.

Timm Friebe wrote the RFC: Catchable “call to a member function of a non-object”, which aims to raise non-fatal E_RECOVERABLE_ERROR errors when one tries to call a method on something else than an object — like NULL, typically.

Rowan Collins started a thread on error handling and exceptions: re-thinking those could have some benefits (and a new major version would indeed be a good opportunity). The discussion has mostly revolved around the @ operator; and the fact that PHP errors today cover several use-cases.

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 jeudi 24 avril 2014

Cet article est aussi disponible en français.

BTW, here’s the RSS feed of the posts I might write in English — oh, and if you know someone at planet-php and feel these posts have their place there, feel free to point them to this blog ;-).

This month of March 2014 has seen 611 mails on PHP’s internals@ mailing-list — which is a bit less than the month before which had more than 950 mails!

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

We can feel the feature-freeze of PHP 5.6 is getting close: not much related to RFCs has happened this month, and the rhythm of new discussions and ideas has slowed down compared to the previous months!

On March 7, PHP 5.6-alpha3 has been released. It should be the last alpha version for PHP 5.6, as a first bêta is planned for the end of the month1.

This first bêta version will indicate the feature-freeze for PHP 5.6: no new feature or change shall be accepted for this version.

Following discussions started since a couple of months about a future major version of PHP, Julien Pauli posted a list of changes that could be made on the PHP engine itself.

Rasmus Lerdorf quickly noted this list was extremely ambitious (re-write of several components, including some difficult parts). That being said, as Pierre Joye answered, it should be possible to deal with at least some of these ideas.

Another factor that must be taken into account is that only a small portion of PHP contributors today have the knowledge required to work on these points — and not too many thing should be modified at the same time!

Still, where a minor version cannot break compatibility as seen be the language’s users, it doesn’t go the same way with internal behavior — which means these features and changes could come with PHP 6.1, 6.2, …

There have already been a few threads about Unicode, and Rowan Collins tried to summarize what Unicode support means.

He started with the fact that, today, a PHP string is nothing more than a stream of bytes — and this notion cannot disappear (for instance, it will remain useful to store binary data such as images). He then asked what the real needs are, when it come to text manipulation, for users — those needs not necessarily being tied to the internal representation of a string. Finally, he noted we have to think about an implementation that allows PHP to answer those needs.

Basically, most people seems to agree on the idea that strings should be represented, internally, as a Unicode charset. But let’s not forget that Unicode can actually correspond to four distinct encodings

In the conversation, a question has been asked: should PHP accept identifiers (variable names, functions names, …) that are not ASCII? Considering the complexity that comes with Unicode, it seems for now the answer is no. Still, today with PHP 5.x, we are not limited to ASCII ;-).

Discussions will probably go on for a few month, before arriving to a solution that suits the needs: on this specific matter, the next PHP major version is expected by many!

Now that several PHP interpreters and compilers exist (HHVM from Facebook, KittenPHP form Vkontakte, the compiler to bytecode for the JVM JPJP, HippyVM when it comes to Python, …), each one of these tends to implement features that don’t exist in the original php.net’s engine, or to not implement some points that one does.

As a consequence, Ivan Enderlin noted the need for a PHP specification was getting real — and internals@ could work on the redaction of such a standard, as this mailing-list of developpers has some weight2 on the language. This specification would be a logical next step after the RFCs began structuring the process of adding new features, those last years.

Johannes Schlüter answered that, as long as PHP is the reference implementation, every new feature must be implemented by this one to be considered as a part of the language. Of course, this answer goes against the idea of a specification, where the implementation that respects it should only arrives in second place.

On the other side, Andrea Faulds noted that a reference implementation is not a real specification, as a bug of that implementation can well be considered as a feature of the language. And it’s certainly something that happens, as the answer to “what should PHP do?” is often “what php-src does now”!

An idea might be to write this specification at the same time the next major version of PHP is developed. This way, the specification would reflect the reality of the implementation of PHP 6, and, at the same time, provide goals for other future implementations.

The discussion settled down at the end of the month. I’m curious to see how this proposal will evolve in the future, especially when development on PHP 6 will really begin!

Several long discussions have taken place in March about changes recently made to the sessions extension.

Andrey Andreev wrote the RFC: Sessions: Improve original RFC about lazy_write, which aims to improve the idea brought by RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy.

Julien Pauli noted the two new functions session_reset() and session_abort() that have been added recently did not raise an error when called with no initialized session — contrary to all other session-related functions. This should be fixed.

That being said, Andrey Andreev said a couple of times that these two functions were added a bit fast and did not bring much value — and, as such, he asked for them to not be added in PHP 5.6, to leave time for more thinking.

After a while, Julien Pauli insisted on the fact that PHP 5.6’s feature-freeze was getting close, and that deeper changes to the session extension could be made for the next major version of PHP.

After RFC: TLS Peer Verification passed, Chris Wright submitted a patch that enables peers verification for Windows without users having to set up any specific configuration. As it should help users a lot, it has been merged.

As Philip Sturgeon said after RFC: Array Of was rejected, a possibility for the future would be a support of Array of with a syntax close to Generics for PHP 5.7, followed by full support of Generics for PHP 6.

Combining the new power operator ** and the possibility of using expressions when defining constants, Tjerk Meesters proposed to merge to PHP 5.6 a Pull-Request that allows this kind of syntax:

const FOO = 2 ** 3 ** 2;

Last but not least, Jakub Zelenka announced a new JSON parser, under PHP license (this should solve problems that rose up a couple of months ago), which brings a nice performance and memory gain.

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

  1. Actually, the first bêta version for PHP 5.6 has only been officially announced on April 11th

  2. Ivan wrote the php.net implementation was “the historical one”. Please note this word doesn’t have in French (which is Ivan’s 1st language) the meaning it has in English: he actually meant php.net implementation was the first interpreter for PHP — and not that it’s in any way outdated or anything like that. Still, as this word caused a few comprehension problems, it would be better to use another one like original implementation or first implementation ^^