Pascal MARTIN (n+1).zéro

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):

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.

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):

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 month¹.

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 weight² 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.

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) :

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 mars¹.

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 historique² 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.

Tu étais devant ton PC, tu devais jouer.

Combien de fois ai-je entendu cette phrase ou une remarque du même acabit¹ ?

Lorsque ce sont des amis ou de la famille² qui prononcent ces mots, j’essaye d’expliquer rapidement ce que je fais de mes journées et à quoi servent les applications et projets sur lesquels j’interviens. Je n’y arrive pas toujours très bien, mais je progresse !

Lorsque c’est un collègue qui fait le même métier que moi³ qui dit ça, je sais qu’il est animé par la même étincelle que moi⁴ : nous avons la chance de faire quelque chose qui, souvent, nous amuse !

Mais lorsque ces mots sortent de la bouche de quelqu’un d’autre, voila des années que je contiens ma colère et que je réponds d’un timide “nan mais des fois je bosse, hein, aussi”, alors que j’ai plus tendance à avoir une de ces pensées :

Mes cinq ans d’études et mon diplôme, j’ai dû les trouver dans une pochette surprise !

Ou :

Depuis 8 ans que je fais ce métier, tu ne crois pas que mes patrons s’en seraient rendu compte, si je passais mes journées à jouer et que je n’étais pas productif ?

Voire même, dans les rares cas où cette remarque est venue d’un collègue exerçant un autre métier que le mien :

Oui, bien sûr : à partir de demain, tu bosses pour deux, puisque notre patron t’a recruté pour bosser et moi pour jouer.

Avec le recul, je me dis que, des fois, je devrais peut-être répondre moins timidement…

Bien sûr, ça ne m’empêche pas de jouer⁵, y compris au bureau !

Mais dans ce cas, ça se voit clairement, c’est aux heures de pause ou le soir, je ne suis pas devant mon PC mais dans un canapé devant la console et une TV — et c’est excellent pour la cohésion et le moral de l’équipe !

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) :

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.