Par Pascal MARTIN le mardi 7 octobre 2014

Cet article est aussi disponible en français.

730 messages have been exchanged in September 2014 on PHP’s internals@ mailing-list — almost the same number as in August.

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

At the beginning of the month, Andrea Faulds wrote an RFC called “Implicit isset() in Shorthand Ternary Operator”. Its idea was to modify the ?: operator introduced with PHP 5.3 to automatically add an isset() and, so, prevent any notice from being raised.

The first answers indicated that the idea could be interesting, but, at the same time, several voices said changing the behavior of ?: in such a way might not be quite a good idea.

In the end, most of this RFC has been rewritten, leading to RFC: Null Coalesce Operator. The idea is now to add a new ?? operator, instead of changing the behavior of ?:. This new operator can be used like this:

// Uses $_GET['user'] if it exists -- or 'nobody' if it doesn't
$username = $_GET['user'] ?? 'nobody';

// Loads some data from the model and falls back on a default value
$model = Model::get($id) ?? $default_model;

With 31 votes “yes” and 3 votes “no”, this revamped version of the RFC has passed, which means PHP 7 will have a new ?? operator.

Leigh has written the RFC: loop + or control structure, which aims to add an optional block to PHP loops (for, while, foreach). This block would be executed in cases we don’t enter inside the loop (as the condition has not been true, even at first try). It would be introduced by the or keyword.

With this RFC, we could write something like this:

foreach (generator() as $k => $v) {
    // loop body
or {
    // executed if we never entered the
    // body of the foreach loop

This feature already exists in some templating languages — for instance, it is supported by Twig for its for loops, using the else keyword.

Note: using or would mean not adding a new reserved word, and else, which is used by other languages, cannot be used for PHP as it would lead to ambiguities in the language.

A few other things have been talked about in the conversation (we’ll see if someone pushes them farther, via other RFCs?), like the idea for a loop to systematically return the number of iterations done.

Robert Stoll suggested PHP 7 might be an occasion to make transtyping operations more strict. For example, (int)"a" would not longer be 0 and it would raise an error. Andrea Faulds quickly answered that explicit casts cannot fail and changing this behavior now would cause an incredible amount of bugs and BC-breaks.

Still, it might be possible to add some new transtyping functions that would be more strict — maybe like ext/filter already does? Another approach could be to use new keywords, like int('2'), or even a syntax close to constructors, like $a = new int('2').

Nikita Popov has written the RFC: Remove alternative PHP tags, which proposes to remove, for PHP 7, the alternative tags <% ... %> and <script language="php"> ... </script>.

Several answers have been quite positive, but others noted a script to facilitate the migration to <?php ... ?> would be helpful.

Votes have been opened a few days before the end of the month and results should be there at the beginning of October. For now, things seem to be going well for this RFC.

Levi Morrison noted that what is usually called type-hints are definitely not hints, as types fixed when declaring a function or a method are checked and an error is raised if passed parameters don’t match them. As a consequence, he asked if someone had a better name idea, or if we were going to keep calling those hints.

Andrea Faulds suggested Optional Type Declarations for parameters and Return Type Declaration for the return-type. As those types are not optional once they are set, Type Declarations might be a good compromise — or maybe Type Assertions.

On the other hands, Type Hints has been used for years in the manual and by the community… In the end, I’m curious to see if this proposal will go farther and if, one day, we’ll stop talking of hints for things that are actually not.

Tjerk Meesters noticed the tests of ReflectionFunction::isDeprecated() depend, for now, on functions flagged as deprecated — but, as those might get removed for PHP 7, these tests might have to be updated.

That test might also be fixed, so it finds a deprecated function by itself. Or, instead, would it not be interesting for PHP to define a __deprecated__() function, that would forever be flagged as deprecated — even if it would only exist when PHP is compiled in debug-mode?

During the conversation, Alexander Lisachenko noted that adding a deprecated keyword, that could be used from user-space, might be an interesting idea, especially for some big frameworks. I wonder if this idea has not already been suggested in the past…

Dmitry Stogov has written the RFC: Fix list() behavior inconsistency, which suggests to remove a few inconsistencies of list() when it comes to strings. Today, using list() on a string works, or not, depending on the situation:

list($a,$b) = "aa"; // $a and $b are NULL
$a[0]="ab"; list($a,$b) = $a[0]; // $a is 'a' and $b contains 'b'

For PHP to be more consistent, this RFC proposed to forbid using list() on strings, or to make it work in all cases. As Derick Rethans indicated, the second option would add a new behavior to PHP, while the first one would come to removing something that works today (even if not documented).

Votes have been opened right before the end of September. Considering how things are going for now, it is very likely something will be done, but it’s hard to predict which one of those two approaches will win.

I was saying last month a mailing-list had been setup for members of the French UG AFUP, to discuss, in French, about proposals that were announced on internals@.

Following our discussions of this month, I (as I’m acting as its coordinator) posted a summary of AFUP’s members’ opinion on three threads:

In addition, we now have a blog. I’ll try posting, mainly in French, about the opinions we have expressed on internals@, and, if possible, a few sentences to summarize the goal of each RFC and why we’ve spoken the way we did: PHP Internals en français

Matt Wilmas worked on a patch that would bring a micro-second resolution (with a good precision) to functions such as microtime(). It might be added to a next minor version of PHP 5.6.

Andrea Faulds opened votes on RFC: Scalar Type Hinting With Casts, before pausing them to give people more time to discuss the matter… And, in the end, the RFC has been withdrawn.

Leigh proposed adding two new format codes to pack() and unpack(), related to 64 bits. RFC: 64 bit format codes for pack() and unpack() has been posted a few days later. This RFC passed, with 15 votes “yes” and 0 votes “no”.

Here’s another RFC written by Andrea Faulds: RFC: ZPP Failure on Overflow. It started off the fact that, today, when a floatting-point number too big to fit in the range of an integer is passed as a parameter to an internal function (exposed by PHP or an extension) that expects an integer, it is received by this function as… an integer… which causes loss of data. This RFC proposes that, when an integer is expected as a parameter and the received value is a float that cannot fit in an integer, the parsing of the parameters of the function fails, and a warning gets raised.

At the beginning of the month, Levi Morrison announced votes were being opened on RFC: Make defining multiple default cases in a switch a syntax error. With 28 votes “yes” and 0 votes “no”, it passed: it will not be possible anymore, with PHP 7, to write more than one default section in a single switch construct.

In the middle of September, Andrea Faulds indicated the beginning of the voting phase on RFC: Integer Semantics. With 16 votes “yes” and 8 votes “no”, it seems this RFC passed — even if votes got closed pretty much a day too early.

Kris Craig wrote the RFC: Change checkdnsrr() $type argument behavior, to change the default behavior of checkdnsrr(), to fetch more than only MX records.

And, finally, Nicolai Scheer noticed it isn’t possible to use an object as an array key, even if it defines a __toString() method: this one is not automatically called. Calling __toString() automatically in such a situation doesn’t seem right, as this method is used by some to produce a printable version of an object. Instead, a new magic method __toKey() could be added, so __toString() continues to return a printable string, while this new method would return a more technical identifier. 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://

Par Pascal MARTIN le mardi 7 octobre 2014 1 commentaire

This post is also available in English.

Septembre 2014 a vu 730 messages échangés sur la mailing-list internals@ de PHP, soit quasiment le même nombre qu’en août.

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

Je disais le mois dernier qu’une mailing-list avait été mise en place pour les membres de l’AFUP, en vue d’échanger en français sur les propositions annoncées sur internals@.

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

En complément, nous disposons maintenant d’un blog où j’essayerai de poster régulièrement, principalement en français, les opinions que nous avons exprimées sur internals@, ainsi que, dans la mesure du possible, quelques phrases résumant en quoi consistent chaque RFC et pourquoi nous nous sommes exprimés comme nous l’avons fait : PHP Internals en français

Au début du mois, Andrea Faulds a rédigé une RFC nommée “Implicit isset() in Shorthand Ternary Operator”, qui proposait de modifier l’opérateur ?: introduit avec PHP 5.3 pour qu’un isset() soit automatiquement ajouté et, donc, qu’aucune notice ne soit levée.

Les premiers retours ont montré que l’idée pouvait être intéressante, mais, en parallèle, plusieurs voix ont souligné qu’il n’était peut-être pas judicieux de modifier le comportement de l’opérateur ?: de la sorte.

Finalement, cette RFC a été en grande partie ré-écrite, pour arriver à RFC: Null Coalesce Operator, qui proposait d’ajouter un nouvel opérateur ??, au lieu de modifier le comportement de ?:. Ce nouvel opérateur pourrait être utilisé de la manière suivante :

// Utilise $_GET['user'] si existe et 'nobody' sinon
$username = $_GET['user'] ?? 'nobody';

// Charge une donnée depuis le modèle et se rabat sur une valeur par défaut
$model = Model::get($id) ?? $default_model;

Avec 31 votes “pour” et 3 votes “contre”, cette version revue de la RFC est passée et PHP 7 disposera donc d’un nouvel opérateur ??.

Leigh a rédigé la RFC: loop + or control structure, qui propose d’ajouter un bloc, optionnel, aux structures de boucles (for, while, foreach) de PHP. Ce bloc serait exécuté dans le cas où on n’entre jamais dans la boucle (la condition n’étant pas vérifiée, et ce dès le premier passage). Il serait introduit par le mot-clef or.

Avec cette RFC, il deviendrait possible d’écrire quelque chose de ce type :

foreach (generator() as $k => $v) {
    // corps de la boucle
or {
    // exécuté si on n'est pas entré
    // dans le corps de la boucle foreach

C’est une fonctionnalité qui existe déjà dans certains langages de templating — par exemple, Twig supporte ceci pour ses boucles for, en utilisant le mot-clef else.

Il est à noter qu’utiliser or éviterait d’ajouter un nouveau mot réservé et que le mot-clef else employé par d’autres langage ne semble pas pouvoir être utilisé par PHP, car il mènerait à des ambiguïtés.

Quelques autres idées ont été levées dans la conversation (à voir si quelqu’un les poussera en avant à travers d’autres RFC ?), comme la possibilité qu’une boucle puisse systématiquement retourner le nombre d’itérations effectuées.

Robert Stoll a suggéré que PHP 7 pourrait être l’occasion de rendre les opérations de transtypage plus strictes, de manière à ce que, par exemple, (int)"a" ne vaille plus 0 et lève une erreur. Andrea Faulds a rapidement répondu que les casts explicites ne pouvaient pas échouer et que changer ce comportement maintenant mènerait à une quantité incroyable de bugs et de BC-breaks.

Par contre, une possibilité pourrait être d’ajouter de nouvelles fonctions de transtypage plus strictes — peut-être comme ce que fait déjà ext/filter ? Passer par de nouveaux mot-clefs comme int('2') ou même une syntaxe proche de celle utilisée pour les constructeurs, comme $a = new int('2'), pourrait être une autre approche.

Nikita Popov a rédigé la RFC: Remove alternative PHP tags, qui proposait de supprimer, pour PHP 7, les tags alternatifs <% ... %> et <script language="php"> ... </script>.

Une partie des retours ont été plutôt positifs, mais d’autres ont souligné qu’il serait bon de fournir un script facilitant la migration vers <?php ... ?>.

Les votes ont été ouverts vers la fin du mois et les résultats devraient arriver tout début octobre — les choses semblant plutôt bien parties pour cette RFC pour l’instant.

Levi Morrison a noté que ce qui est généralement appelé type-hints ne sont absolument pas des hints (“hint” se traduisant par “indice” ou “astuce”), puisque les types indiqués lors de déclarations de méthodes et fonctions sont vérifiés et que des erreurs sont levées si les paramètres passés ne correspondent pas à ceux-ci. Il a donc demandé si quelqu’un avait une meilleure proposition de nom, ou s’il fallait rester sur celui-ci.

Andrea Faulds a proposé Optional Type Declarations pour les paramètres et Return Type Declaration pour le type de retour. Ces types n’étant pas optionnels une fois qu’ils ont été positionnés, Type Declarations constituerait un bon compromis — ou peut-être Type Assertions.

D’un autre côté, Type Hints est utilisé depuis des années dans le manuel et par la communauté… Je suis donc curieux de voir si cette proposition aboutira et si on cessera un jour de parler de hints pour quelque chose qui n’en est pas.

Tjerk Meesters a remarqué que les tests de la méthode ReflectionFunction::isDeprecated() dépendent, aujourd’hui, de fonctions marquées comme obsolètes — mais, comme elles pourraient être supprimées de PHP 7, ces tests seront à revoir.

Le test en question pourrait aussi être modifié pour trouver par lui-même une fonction obsolète. Ou, à la place, est-ce qu’il ne serait pas intéressant que PHP définisse une fonction __deprecated__(), qui soit éternellement marquée comme obsolète — quitte à ce qu’elle n’existe que lorsque PHP est compilé en mode debug ?

Dans la conversation, Alexander Lisachenko a noté qu’ajouter un mot-clef deprecated qui puisse être utilisé depuis l’espace utilisateur serait peut-être une alternative intéressante, notamment pour certains gros frameworks. Je me demande d’ailleurs si cette idée n’avait pas déjà été évoquée par le passé…

Dmitry Stogov a rédigé la RFC: Fix list() behavior inconsistency, qui proposait de supprimer quelques inconsistences de list() par rapport aux chaînes de caractères. En effet, aujourd’hui, utiliser list() sur une chaîne de caractères fonctionne ou non selon les cas :

list($a,$b) = "aa"; // $a et $b valent NULL
$a[0]="ab"; list($a,$b) = $a[0]; // $a vaut 'a' et $b vaut 'b'

Pour rendre PHP plus cohérent, cette RFC proposait de complètement interdire l’utilisation de list() sur des chaînes de caractères, ou alors que la rendre possible dans tous les cas. Comme l’a fait remarquer Derick Rethans, la seconde option ajouterait un comportement fonctionnel à PHP, alors que la première reviendrait à supprimer quelque chose qui marche aujourd’hui (même si non documenté).

Les votes ont été ouverts quelques jours avant la fin du mois. Vu l’orientation qu’ils prennent, il est fort probable que quelque chose soit fait, mais il est difficile de prédire laquelle des deux approches sera privilégiée.

Matt Wilmas a travaillé à un patch permettant d’avoir une résolution à la microseconde (avec une bonne précision) pour les fonctions comme microtime(). Il pourrait être intégré pour une prochaine version mineure de PHP 5.6.

Andrea Faulds a ouvert les votes sur la RFC: Scalar Type Hinting With Casts, avant de les mettre en pause pour laisser le temps à plus d’échanges sur le sujet… après lesquels la RFC a été retirée.

Leigh a proposé d’ajouter de nouveaux codes de formats à pack() et unpack(), pour ce qui est 64 bits. La RFC: 64 bit format codes for pack() and unpack() a été rédigée quelques jours plus tard. Cette RFC est passée, avec 15 votes “pour” et 0 vote “contre”.

Voici une autre RFC proposée par Andrea Faulds : RFC: ZPP Failure on Overflow. Elle est partie du constat que, aujourd’hui, lorsqu’un flottant trop grand pour tenir dans les valeurs supportées pour les entiers est passé en paramètre à une fonction interne (fonction exposée par PHP ou par une extension PHP) qui attend un entier, il est reçu par la fonction sous la forme… d’un entier… ce qui entraîne une perte d’information. Cette RFC propose donc que, dans le cas où un paramètre entier est attendu et que la valeur reçue est un flottant trop grand pour tenir dans un entier, l’analyse des paramètres de la fonction interne appelée échoue, que la fonction retourne sans s’exécuter, et qu’un avertissement soit levé.

Au début du mois, Levi Morrison a annoncé l’ouverture des votes sur la RFC: Make defining multiple default cases in a switch a syntax error. Avec 28 votes “pour” et 0 vote “contre”, elle est passée : il ne sera donc plus possible, en PHP 7, d’écrire plusieurs sections default dans un même bloc switch.

En milieu de mois, Andrea Faulds a annoncé l’ouverture des votes sur la RFC: Integer Semantics. Avec 16 votes “pour” et 8 votes “contre”, elle semble être passée — même si les votes ont été clos pas loin d’un jour en avance.

Kris Craig a rédigé la RFC: Change checkdnsrr() $type argument behavior, qui propose de modifier le comportement par défaut de la fonction checkdnsrr() pour charger plus que les informations d’enregistrements MX.

Et enfin, Nicolai Scheer a fait remarquer qu’il n’était pas possible d’utiliser un objet comme clef d’un tableau, même s’il définissait une méthode __toString() : celle-ci n’est pas automatiquement appelée. Appeler automatiquement __toString() dans ce cas de figure ne semble pas optimal, puisque cette méthode est utilisée par certains pour produire une version affichable d’un objet. À la place, une nouvelle méthode magique __toKey() aurait l’avantage de laisser à __toString() le soin de renvoyer une chaîne utilisable pour affichage, alors que cette nouvelle méthode renverrait un identifiant plus technique. 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://

Par Pascal MARTIN le mardi 23 septembre 2014 4 commentaires

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Par Pascal MARTIN le mercredi 17 septembre 2014 3 commentaires

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

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

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

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

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

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

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

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

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

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

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

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

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

Nous croiserons-nous à ce Forum PHP ?

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

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

Par Pascal MARTIN le mercredi 10 septembre 2014

Cet article est aussi disponible en français.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dmitry Stogov set up a new memory manager for PHP 7. The matter has not been discussed much, but it seems this manager brings some performance gain — even it it might be relatively limited. 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://