129 posts taggués « php »

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 ^^ 

Par Pascal MARTIN le mardi 22 avril 2014 1 commentaire

This post is also available in English.

L’année se poursuit avec un mois de mars 2014 de 611 messages sur la mailing-list internals@ de PHP — ce qui donne un mois plus calme que le précédent, qui était à plus de 950 mails !

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

On sent que le feature-freeze de PHP 5.6 arrive : ce mois-ci n’a vu que peu de mouvement au niveau des RFC et le rythme de nouvelles discussions et idées s’est calmé par rapport aux mois précédents !

En début de mois, le 7 mars, PHP 5.6-alpha3 a été publiée. Il devrait s’agir de la dernière version alpha de PHP 5.6, une première version bêta étant prévue pour la fin du mois de mars1.

Cette première version bêta correspondra au feature-freeze de PHP 5.6 : plus aucune nouvelle fonctionnalité ou changement ne pourra être intégré pour cette version.

Dans la suite des discussions déjà entamées sur les mois précédents à propos d’une prochaine version majeure de PHP, Julien Pauli a posté une liste de changements qui pourraient / devraient être apportés au moteur de PHP.

Il n’a pas fallu longtemps à Rasmus Lerdorf pour faire remarquer que cette liste était extrêmement ambitieuse (ré-écriture de nombreux composants, y compris parties pas évidentes à prendre en main). Cela dit, comme l’a souligné Pierre Joye, il pourrait être envisageable de traiter au moins une partie de ces points.

Un autre frein à prendre en compte est que seule une petite partie des contributeurs à PHP ont aujourd’hui les connaissances requises pour travailler sur ces points — sans compter qu’il ne faut pas changer trop de choses à la fois !

Heureusement, là où une version mineure ne peut pas casser la compatibilité telle que vue par les utilisateurs du langage, il n’en n’est pas de même pour son fonctionnement interne — ce qui signifie que ces nouveautés pourraient être apportées par PHP 6.1, 6.2, …

Alors qu’il y a déjà eu plusieurs fils de discussion sur le sujet d’Unicode, Rowan Collins a essayé de résumer ce que support d’Unicode signifie.

Il a commencé par rappeler qu’aujourd’hui, une chaîne de caractères PHP n’est en fait qu’une suite d’octets — mais que cette notion ne doit pas disparaître (ne serait-ce que pour représenter des données binaires, comme des images). Il a ensuite demandé quel étaient les réels besoins, en termes de manipulation de texte, pour les utilisateurs — ceux-ci n’étant pas nécessairement liés à la représentation interne d’une chaîne de caractères. Enfin, il a noté qu’il convient de réfléchir à une implémentation qui permette de répondre à ces besoins.

Globalement, la majorité semble d’accord sur le fait que les chaînes devront être représentées, en interne, par un jeu de caractères Unicode. Mais n’oublions pas non plus que Unicode peut en fait correspondre à quatre encodages différents…

Dans le courant de la conversation, une interrogation a été levée : PHP doit-il accepter des identifiants (noms de variables, de fonctions, …) sortant du jeu de caractères ASCII traditionnel ? Considérant la complexité introduite par Unicode, il semblerait pour l’instant que non. Notons tout de même que, aujourd’hui en PHP 5.x, nous ne sommes pas limités à ASCII ;-).

Les discussions se poursuivront probablement pendant encore quelques mois, avant d’arriver à une solution acceptée par le plus grand nombre : sur ce point précis, la prochaine version majeure de PHP est très attendue !

Alors que plusieurs interpréteurs et compilateurs PHP existent (HHVM de Facebook, KittenPHP de Vkontakte, le compilateur vers du bytecode pour la JVM JPJP, HippyVM pour ce qui est Python, …), chacun d’entre eux a tendance à fournir des fonctionnalités qui n’existent pas dans l’interpréteur historique, ou à ne pas implémenter certains des points que celui-ci sait gérer.

En conséquence, Ivan Enderlin a noté que le besoin d’une spécification pour PHP se faisait de plus en plus important — internals@ pouvant être responsable de la rédaction d’un tel standard, de par le poids historique2 de cette mailing-list des développeurs de PHP. Ce standard serait une suite logique aux RFC qui ont commencé à structurer le processus d’ajout de fonctionnalités ces dernières années.

Johannes Schlüter a rapidement répondu que tant que PHP était l’implémentation de référence, toute nouvelle fonctionnalité doit être mise en place au sein de celle-ci pour faire partie du langage. Bien sûr, cette réponse est en totale opposition avec l’idée de spécification, où l’implémentation qui respecte celle-ci ne devrait arriver qu’en second.

En face, Andrea Faulds a noté qu’une implémentation de référence n’était pas une réelle spécification, un bug de celle-ci pouvant être considéré comme une fonctionnalité du langage. Et c’est chose qui arrive, puisque la réponse à “qu’est-ce que PHP doit faire ?” est souvent “ce que php-src fait maintenant” !

Une proposition serait d’écrire cette spécification en parallèle du développement de la prochaine version majeure de PHP. De la sorte, celle spécification reflétera la réalité de l’implémentation de PHP 6, tout en fournissant des objectifs pour de futures implémentations.

La discussion s’est calmée en fin de mois. Je suis curieux de voir ce que l’idée donnera dans le futur, en particulier alors que les développements sur PHP 6 commenceront réellement !

Ce mois de mars a vu de nombreuses — et longues — discussions autour de modifications apportées récemment à l’extension de gestion de sessions.

Andrey Andreev a rédigé la RFC: Sessions: Improve original RFC about lazy_write, qui vise à améliorer l’idée précédemment apportée par la RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy.

Julien Pauli a fait remarquer que les deux fonctions session_reset() et session_abort() ajoutées il y a peu ne levaient pas d’erreur en cas de session non initialisée — contrairement aux autres fonctions de gestion de sessions. Ce point devrait être corrigé.

Cela dit, Andrey Andreev a déjà noté plusieurs fois que ces deux fonctions avaient été ajoutées un peu rapidement et n’apportaient pas de réelle valeur ajoutée — et il a donc demandé leur suppression de PHP 5.6, afin de laisser plus de temps de réflexion.

Au bout d’un moment, Julien Pauli est intervenu pour rappeler que le feature-freeze de PHP 5.6 était proche, et qu’il serait possible d’apporter des modifications plus profondes au fonctionnement du module de sessions d’ici la prochaine version majeure de PHP.

Suite à l’acceptation de la RFC: TLS Peer Verification, Chris Wright a proposé un patch qui permet d’obtenir un support de la vérification de peers sous Windows sans avoir à mettre en place de configuration spécifique. Celui-ci visant à grandement faciliter la vie des utilisateurs, il a été accepté.

Comme l’a dit Philip Sturgeon suite au rejet de la RFC: Array Of, une piste pour le futur serait un support de Array of avec une syntaxe de type Generics pour PHP 5.7, suivi d’un réel support complet des Generics pour PHP 6.

Combinant l’ajout du nouvel opérateur de puissance ** et la possibilité d’utiliser des expressions lors de la définition de constantes, Tjerk Meesters a proposé de merger vers PHP 5.6 une Pull-Request permettant d’utiliser ce type de syntaxe :

const FOO = 2 ** 3 ** 2;

Pour finir, Jakub Zelenka a annoncé la création d’un nouveau parser JSON, sous licence PHP (ce qui résoudrait les problèmes évoqués il y a quelques mois), qui apporte un gain non négligeable en performances et en mémoire.

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, la première version bêta de PHP 5.6 n’est sortie que le 11 avril

  2. Historique signifiant (du moins en français — puisque le français est la 1ère langue d’Ivan Enderlin) que l’implémentation fournie par php.net est le premier interpréteur apparu pour PHP — et nullement que celui-ci est dépassé. Ce terme n’ayant pas la même signification en anglais, il a causé quelques problèmes de compréhension, et gagnerait à être remplacé par implémentation originale ou première implémentation ^^ 

Par Pascal MARTIN le jeudi 20 mars 2014 5 commentaires

This post is also available in english.

L’année 2014 se poursuit avec un mois de février bien rempli, avec 972 messages sur la mailing-list internals@ de PHP — quasiment le même nombre que le mois précédent !

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

Tout juste au milieu du mois, PHP 5.6-alpha2 a été publiée.

Deux semaines après, Ferenc Kovacs a annoncé que la version alpha3 (tagguée en fin de mois) serait suivie de la première version bêta aux environs de mi-mars — ce qui devrait laisser deux semaines pour merger les fonctionnalités en cours de travail vers PHP 5.6, la phase de versions bêta correspondant au feature-freeze.

Alors que la sortie de PHP 5.6 se rapproche, l’idée d’une prochaine version majeure, peut-être “PHP 6” (ou peut-être “PHP 5++”, puisque le seul fait de choisir un numéro de version risque de demander une sérieuse discussion), refait de plus en plus souvent surface depuis quelques mois. La vieille page todo:php60 du wiki de PHP a même été ressortie, même s’il vaudrait mieux s’assurer de ne pas perdre son historique.

Un des points majeurs est la gestion de l’Unicode : globalement, tout le monde semble d’accord pour dire que PHP 6 devra gérer l’Unicode. Par contre, comment est une réelle question ! Plusieurs liens sur le sujet ainsi qu’un récapitulatif ont d’ailleurs été postés. Une première étape, au moins pour la phase de développement, serait de passer par un flag “supporte UTF-8” qui serait pris en compte par les fonctions modifiées pour gérer l’Unicode — les autres continuant à travailler par octets comme elles le font aujourd’hui.

Pierre Joye a indiqué qu’il avait mis ses idées à propos de PHP 6 sur papier : ideas:php6. Cette page vise à regrouper les propositions sur lesquelles il estimait intéressant d’échanger ou de travailler plus en profondeur. Stas Malyshev a répondu avec sa propre liste, suivi par Julien Pauli ainsi que d’autres.

Au passage, Marc Bennewitz a demandé si PHP 6 ne serait pas l’occasion de supprimer le type resource, quitte à le transformer en une classe Resource. En effet, comme l’a souligné Chris Wright, les ressources ressemblent à un peu à un moyen tordu de travailler avec des objets, et en convertir autant que possible en classes spécifiques permettrait souvent de déterminer plus facilement ce à quoi correspond une ressource.

Tjerk Meesters a indiqué que la RFC: Power Operator était passée, avec 22 votes “pour” et 9 votes “contre”. PHP 5.6 intégrera donc un nouvel opérateur de puissance symbolisé par ** :

~/bin/php-5.6-debug/bin/php -a
Interactive shell

php > printf("2 ** 3 = %d\n", 2 ** 3);
2 ** 3 = 8

Suite à plusieurs discussions sur les semaines précédentes, Rouven Weßling a annoncé l’ouverture des votes sur la RFC: Timing attack safe string comparison function.

Bien sûr, le nom hash_compare() proposé n’a pas semblé faire l’unanimité, mais aucune proposition faite précédemment n’a non plus convaincu — et la discussion a duré depuis mi-décembre. En parallèle, Yasuo Ohgaki a rapidement fait remarquer que, les timing attacks étant déjà possibles aujourd’hui, il serait d’après lui bon d’inclure cette nouvelle fonction sans attendre PHP 5.6.

Finalement, l’idée derrière cette RFC est passée avec 22 voix “pour” et 1 voix “contre”. Le choix de l’implémentation n’étant pas encore effectué, il n’est pas dit si hash_compare() arrivera pour PHP 5.6 ou 5.7 — cette fonction étant assez sensible, il n’est pas surprenant que sa mise en place soit discutée après que son principe ait été validé.

Suite à une longue discussion autour de la fonction uniqid() qui génère un nombre aléatoire “non-sûr”, Yasuo Ohgaki a annoncé avoir rédigé la RFC: Build OpenSSL Module by Default proposant de systématiquement inclure openssl. Jan Ehrhardt a répondu en postant un lien vers l’extension crypto qui fournit un wrapper autour de la bibliothèque de chiffrement OpenSSL.

En parallèle, Thomas Hruska a proposé d’inclure la fonction mcrypt_create_iv() au cœur de PHP — sous un nom comme rand_bytes() — afin de ne plus dépendre d’une extension, pas toujours activée, pour générer une donnée aléatoire sûre.

Dans la foulée, Pierre Joye a indiqué son souhait d’introduire deux nouvelles directives de configuration visant à unifier la source d’entropie utilisée par les différentes fonctions PHP concernées. Comme noté par Pádraic Brady, l’idéal serait de mettre en place une nouvelle API dédiée, mais cette idée n’est pas réalisable d’ici la sortie de PHP 5.6 — par contre, d’ici PHP 6… Nikita Popov a ensuite posté quelques clarifications quant à cette proposition. Et la RFC: Unify crypt source INI settings est arrivée quelques jours après.

Yasuo Ohgaki a proposé la RFC: Improve HTML escape. Cela dit, comme souligné par Stas Malyshev plus loin dans la conversation, htmlentities() n’est de toute manière pas faite pour échapper des attributs non entourés de guillemets — qui sont valides en HTML5.

Pádraic Brady a ensuite posté un lien vers la RFC: Escaper for PHP Core, qui commence à dater un peu mais allait plus loin. En pratique, d’ailleurs, htmlentities() n’est pas faite pour gérer tous les cas.

Les votes sur cette première RFC ont été ouverts en milieu de mois — et, sans grande surprise considérant les échanges, elle a été rejetée avec 4 votes “pour” et 10 votes “contre”.

Davey Shafik a rédigé la RFC: Combined Comparison (Spaceship) Operator, où il proposait l’ajout d’un nouvel opérateur <=> qui retournerait 0 si les deux opérandes sont égales, 1 si celle de gauche est plus grande que l’autre et -1 si c’est celle de droite qui est la plus grande.

Le nom semble cool, mais une question qui s’est rapidement posée est celle d’une réelle utilité. En pratique, un opérateur de ce type serait particulièrement utile pour des comparaisons dans des contextes de tris — mais une fonction fait déjà très bien l’affaire.

Bien sûr, l’idée de Comparable est revenue sur le tapis dans le cours de la discussion.

Yasuo Ohgaki a lancé l’idée que chaque script PHP puisse indiquer de quelle version minimale de PHP il a besoin pour pouvoir être exécuté.

L’intérêt principal de cette proposition serait d’effectuer cette vérification à la compilation plutôt qu’à l’exécution. Pour l’instant, c’est au gestionnaire de dépendances, comme Composer, que revient cette tâche — et cette proposition peut déjà être implémentée à l’aide de version_compare().

Finalement, l’idée a été abandonnée, la RFC: Expectations, sur laquelle Joe Watkins a continué à travailler, répondant (entre autres) à ce besoin.

Levi Morrison a noté qu’une durée d’une semaine pour la phase de vote de certaines RFC lui semblait court, tous les développeurs n’intervenant pas de manière très regulière sur PHP (sans compter les plages de vacances) et les RFC demandant parfois du temps de réflexion. Cela dit, comme rapidement répondu par Pierre Joye et Andrea Faulds, l’ouverture de la phase de votes est systématiquement précédée d’au moins deux semaines de discussions.

Daniel Lowrey a continué son travail sur la RFC: Improved TLS Defaults. Elle a été ouvertes aux votes en milieu de mois. Et avec 16 votes “pour” et aucun vote “contre”, cette RFC est passée pour PHP 5.6 !

Les votes ont été ouverts sur la RFC: __debugInfo(). Avec 23 votes pour et 3 votes contre, cette RFC est passée et cette nouvelle méthode magique sera présente dès PHP 5.6 !

La RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy a elle aussi été soumise aux votes. Avec 9 votes “pour” et 1 vote “contre”, la première de ces options a été acceptée — les autres étant toutes rejetées.

Yasuo Ohgaki a rédigé la RFC: Secure Session Module Options/Internal by Default où il proposait différentes modifications visant à améliorer la sécurité des sessions fournies par PHP.

Les votes sur la PHP: rfc:automatic_property_initialization avaient été ouverts le tout dernier jour de janvier. Avec 11 votes “contre” et 7 votes “pour”, elle a été rejetée.

Après de longues discussions commencées le mois dernier, Anatol Belski a annoncé que la RFC: 64 bit platform improvements for string length and integer in zval avait été rejetée. Pour résumer, cette modification est trop impactante (au niveau de PHP, mais aussi/surtout au niveau des extensions) pour une version mineure comme PHP 5.6, et aurait plus sa place dans une version majeure comme PHP 6.

Yasuo Ohgaki a noté que la RFC: Optional PHP tags by php.ini and CLI options avait été discutée il y a fort longtemps, et a essayé de relancer le sujet. Stas Malyshev a rapidement répondu qu’une telle proposition ne rendrait que plus difficile la gestion de fichiers PHP, puisque la syntaxe et son analyse dépendrait de paramètres de configuration — sans compter que cela augmenterait les risques de fuite de code-source. Après quelques jours de discussion, Yasuo Ohgaki a annoncé qu’il abandonnait cette RFC.

En toute fin de mois, Philip Sturgeon a ouvert les votes sur la RFC: Array Of — à suivre le mois prochain, donc !

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.