123 posts taggués « php »

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.

Par Pascal MARTIN le jeudi 20 mars 2014 2 commentaires

Cet article est aussi disponible en français.

I’ve been doing a monthly digest of what happens on internals@ for more than a year now, each time in French. Every now and then, some people said it would be nice to have it in English too… So, after december 2013 and last month, here’s my third shot at this!

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 ;-).

2014 keeps going on, with a busy month of february: 972 mails have been sent to the internals@ PHP’s mailing-list — which is pretty much the same number as the previous month!

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

Right in the middle of this month, PHP 5.6-alpha2 has been released.

Two weeks later, Ferenc Kovacs announced the alpha3 version (tagged at the end of the month) would be followed by the first beta version, arround the middle of march — which leaves two weeks to merge features that are still under work to PHP 5.6, as the beginning of the beta versions phase means PHP 5.6 reaches its feature-freeze.

As the release of PHP 5.6 gets closer, the idea of a future major version, maybe “PHP 6” (or maybe “PHP 5++”, as the sole fact of choosing a version number might require a serious debate), has been evoked more and more frequently those last few months. The old todo:php60 wiki page has even been re-linked to, even if it would be nice to not lose its history.

One of the most important point seems to be Unicode: generally speaking, pretty much everyone seems to agree that PHP 6 will have to support Unicode. Still, how is a real question! A few links on the matter, as well as a summary, have been posted. A first step, at least while developping, might be to use a flag “supports UTF-8” that would be used by all functions modified to deal with Unicode — while the others would still work by bytes as they do today.

Pierre Joye said he had put his ideas for PHP 6 on paper: ideas:php6. This page aims to summarize propositions about which it should be interesting to discuss or work in greater details. Stas Malyshev answered with his own list, followed by Julien Pauli and some others.

In the same time, Marc Bennewitz asked if PHP 6 would not be an occasion to remove the resource type, even if it means transforming it to a Resource class. In effect, as noted by Chris Wright, resources feel like an odd way to work with objects, and converting as many as possible to specific classes might often give developpers an easier way to find out what kind of data a resource actually references.

Tjerk Meesters indicated the RFC: Power Operator has passed, with 22 votes “for” and 9 votes “against”. As a consequence, PHP 5.6 will have a new power operator symbolized by **:

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

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

Following several discussions on previous weeks, Rouven Weßling opened votes on RFC: Timing attack safe string comparison function.

Of course, the proposed hash_compare() name didn’t get unanimous approval, but no other proposal did either — and the discussions have been going on since the middle of December. In parallel, Yasuo Ohgaki noted that, as timing attacks are already possible today, it might be good to add this new function to existing versions of PHP, without waiting for PHP 5.6.

In the end, the idea behind this RFC passed with 22 votes “for” and 1 vote “against”. As the implementation has not been fully choosen yet, it is not sure whether hash_compare() will arrive for PHP 5.6 or 5.7 — this function being quite sensitive, its implementation being discussed after the idea has been accepted is not surprising.

After a long discussion about the uniqid() function, which generates an unsafe random number, Yasuo Ohgaki announced the RFC: Build OpenSSL Module by Default, suggesting always including openssl. Jan Ehrhardt answered with a link to the new crypto extension that acts as a wrapper arround OpenSSL’s encryption library.

At the same time, Thomas Hruska proposed to include mcrypt_create_iv() to PHP itself — as a name like rand_bytes() — so we don’t depend on an extension, not always enabled, to generate a safe random piece of data.

After this, Pierre Joye posted about his idea of adding two new configuration options to unify the source of entropy used by the relevant PHP functions. As noted by Pádraic Brady, a good approach would be to set up a new dedicated API, but there is no time to do that before the release of PHP 5.6 — on the other hand, for PHP 6… Nikita Popov then posted a few clarifications about that suggestion. And the RFC: Unify crypt source INI settings has arrived a few days later.

Yasuo Ohgaki has written the RFC: Improve HTML escape. This being said, as noted by Stas Malyshev later, htmlentities() is not built to escape attributes not enclosed in quotes — which are valid in HTML5.

Pádraic Brady then posted a link to the RFC: Escaper for PHP Core, which is a bit older but was going farther. Anyway, though, htmlentities()’s goal is not to deal with just all situations.

Votes on this first RFC have been opened in the middle of the month — and, without much surprise considering the discussions, it has been rejected with 4 votes “for” and 10 votes “against”.

Davey Shafik announced the RFC: Combined Comparison (Spaceship) Operator, in which he suggested we could add a new <=> operator that would return 0 if both its operands are equal, 1 if the one on the left is greater than the other, and -1 if the greatest one is the one on the right.

The name feels cool, but the question of its usefulness has quickly surfaced. Actually, such an operator could be useful for comparisons in contexts such as sorts — but using a function already does the trick.

Of course, the idea of Comparable did come back on the stage during the discussion.

Yasuo Ohgaki started a thread about allowing each PHP script to report the minimal version of PHP it needs in order to be executed.

The main interest behind this proposal would be to do that check during the compilation phase instead of the execution one. For now, it’s typically up to the dependancies manager (such as Composer) to deal with this task — and this idea can already be implemented with version_compare().

In the end, the idea has been dropped, as the RFC: Expectations, on which Joe Watkins kept working, answers this (amongst others) needs.

Levi Morrison said that one week for the voting phase of some RFCs seemed a bit short for him, as not all developpers regularly work on PHP (and there are holidays here and there) and RFCs sometimes require a bit of thinking. That being said, as quickly answered by Pierre Joye and Andrea Faulds, the voting phase is always preceeded by at least two weeks allowing for discussions.

Daniel Lowrey kept working on the RFC: Improved TLS Defaults. It has been opened to votes in the middle of the month. With 16 votes “for” an no vote “against”, this RFC passed for PHP 5.6!

Votes have been opened on the RFC: __debugInfo(). With 23 votes “for” and 3 votes “against”, this RFC passed and this new magic method will arrive with PHP 5.6!

The RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy has too been submitted to voting. With 9 votes “for” and 1 vote “against”, the first one of these options has been accepted — while the others have all been rejected.

Yasuo Ohgaki wrote the RFC: Secure Session Module Options/Internal by Default in which he suggested several modifications aiming to enhance the security of PHP’s sessions.

Votes on the RFC: Automatic property initialization had been opened the very last day of January. With 11 votes “against” and 7 votes “for”, it has been rejected.

After long discussions started last month, Anatol Belski announced the RFC: 64 bit platform improvements for string length and integer in zval has been rejected. Trying to summarize: the changes are too important (for PHP itself, but also/mainly for extensions) for a minor version like PHP 5.6, and would be better suited for a major version like PHP 6.

Yasuo Ohgaki noticed the RFC: Optional PHP tags by php.ini and CLI options had been discussed a long time ago, and tried to revive the subject. Stas Malyshev quickly answered that such a feature would only cause more pain when dealing with PHP files, as the syntax and its parsing would depend on configuration parameters — and it would also increase risks of code-leakage. After a few days of discussions, Yasuo Ohgaki annouced he dropped that RFC.

Right at the end of the month, Philip Sturgeon opened votes on the RFC: Array Of — which means we’ll seen the results next month!

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 lundi 10 février 2014 6 commentaires

This post is also available in english.

L’année 2014 a commencé par un mois de janvier bien rempli, avec 963 messages, soit le double du 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

Le 15 janvier, Ferenc Kovacs a annoncé qu’il allait tagger PHP 5.6-alpha1 — cette version a été publiée quelques jours après, le 24 janvier.

La sortie de cette première version alpha signifie que (en théorie) plus aucune nouvelle RFC ne peut être proposée pour PHP 5.6. Julien Pauli a répondu en souligant qu’aucune RFC ne sera mergée (inclue à PHP 5.6) une fois la phase de versions beta commencée — la première version beta pouvant arriver aux environs de mi-mars.

Adam Harvey a quant à lui commencé à travailler sur la page de documentation Migrating from PHP 5.5.x to PHP 5.6.x.

Certaines fonctionnalités ont été marquées comme obsolètes lors de la sortie de PHP 5.5 : le modificateur /e pour preg_replace(), l’extension ext/mysql, … En suivant le cycle de releases, ces fonctionnalités obsolètes devraient être supprimées de PHP 5.6 (et/ou déplacées vers PECL lorsqu’il s’agit d’extensions comme ext/mysql).

Comme l’a rapidement fait remarquer Andrea Faulds, on trouve encore beaucoup de code utilisant les fonctions mysql_*(), et déplacer l’extension correspondante vers PECL risque de poser quelques problèmes — ceci dit, libre aux distributions de continuer à fournir cette extension. De plus, ce n’est pas parce que nombre de tutoriaux (et quelques logiciels répandus) continuent d’utiliser des fonctions déconseillées depuis des années qu’il faut arrêter de faire évoluer PHP.

Alors que plusieurs idées en cours de discussion apporteraient des modifications plus impactantes que celles vues sur PHP 5.3/4/5, Adam Harvey a demandé s’il ne serait pas temps de commencer à réfléchir à une prochaine version majeure de PHP — c’est une idée qui a déjà été évoquée quelque fois ces derniers mois, d’ailleurs.

Comme l’a fait remarquer Julien Pauli, au-delà des modifications cassant la compatibilité antérieure, une nouvelle version majeure serait aussi l’occasion de faire une passe de ménage — après tout, PHP 5.0 avait bien introduit une nouvelle version du Zend Engine. Ferenc Kovacs a alors noté, comme il l’avait déjà dit il y a quelques mois, qu’aucun processus n’a été jusqu’à présent défini quant à la sortie d’une nouvelle version majeure.

Pour faciliter le passage à cette prochaine version et éviter qu’il ne s’étale sur plus de 5 ans comme ce fût le cas pour PHP 5, une piste serait de profiter de l’existence du FIG pour synchroniser une montée de version au niveau des frameworks les plus utilisés.

Rasmus Lerdorf a rappelé que, selon lui, PHP devrait rester un langage pragmatique, tourné vers le web (les besoins correspondant ont évolué), faiblement typé, et qui prend en compte les besoins et capacités d’un large registre de développeurs. Le support d’Unicode serait indispensable, les performances ne sont pas à oublier, et PDO gagnerait à ce qu’on s’en occupe un peu plus. Tout ceci est moins sexy que de nouvelles fonctionnalités, mais il ne faut pas oublier que ces points répondent aussi à des besoins réels. Julien Pauli a répondu avec quelques idées qu’il avait, comme une VM threadée ou des améliorations et optimisations au niveau de celle-ci.

Andrea Faulds a continué avec un sujet à propos de la sensibilité à la casse en PHP : est-ce qu’une prochaine version majeure ne serait pas l’occasion d’uniformiser un peu, à ce niveau ?

En parallèle, Rasmus Lerdorf a répondu sur un fil de discussion à propos de ce que certains appellent inconsistance dans les noms de fonctions de PHP et les paramètres qu’elles attendent (et l’ordre de ceux-ci) : depuis toujours, PHP a été une sur-couche à des dizaines (des centaines, maintenant) de bibliothèques. Ces fonctions ne sont pas spécifiques à PHP : elles sont inscrites dans la mémoire d’un nombre de développeurs, pas parce que nous écrivons du PHP, mais parce que nous vivons toujours dans un monde écrit en C — et dès que nous nous aventurons hors de PHP et des langages de script, nous rejoignons celui-ci. Ceci dit, comme l’a répondu Larry Garfield, aujourd’hui, seul un petit nombre de développeurs PHP ont connaissance de C ou de POSIX… En fait, C ne doit être la seconde langue que d’un nombre très réduit de développeurs PHP. Suite à ces échanges, un tout début de RFC a été mis en place : RFC: Use alias to provide both legacy and consistent names.

De son côté, Pierre Joye a lancé un troisième sujet de conversation à propos de PHP 6, où il a noté qu’il est important de réfléchir aux impacts que diverses modifications pourraient avoir en termes d’adoption d’une future version du langage (l’idée évoquée plusieurs fois étant d’éviter de se trouver dans une situation équivalente à celle de Python 2 et Python 3).

Alors que HHVM fait de plus en plus souvent parler de lui, zhifeng hu a demandé s’il serait possible de l’introduire dans le code de PHP.

Pierre Joye n’a pas tardé à répondre que, bien qu’intéressante sur de nombreux points, cette idée ne lui semblait pas envisageable pour l’instant, notamment parce que HHVM est contrôlé par une unique entreprise, parce que signer un CLA est nécessaire pour y participer, ou parce qu’il est peu portable (requiert le compilateur GCC). De plus, comme remarqué par Andrea Faulds, HHVM ne correspond pas à une implémentation complète des fonctionnalités de PHP — surtout, comme l’a noté Sara Golemon, pour ce qui est des extensions intégrées ou fournies via PECL.

En somme, cette proposition serait peut-être en avance d’un an ou deux, en l’état actuel de PHP et de HHVM.

Sara Golemon a rédigé la RFC: __debugInfo(), qui vise à exposer à l’espace utilisateur des informations de debuggage déjà connues en interne — en ajoutant une nouvelle méthode magique __debugInfo(). Cette proposition permettrait de personnaliser les sorties de debug.

Parmi les retours, certains ont noté qu’un nom comme __dump() pourrait être plus parlant pour les développeurs PHP ne connaissant pas le fonctionnement interne du moteur, d’autres ont noté que cette fonctionnalité devrait aussi être intégrée à l’API de Reflection. Il a aussi été noté qu’avec une telle fonctionnalité, var_dump() pourrait ne plus toujours afficher la vérité.

Kevin Ingwersen a relancé un sujet à propos de la RFC: Named Parameters, rédigée en septembre 2013, mais qui n’avait plus fait l’objet de discussion depuis quelques temps.

Nombreux sont ceux qui aimeraient voir ce type de fonctionnalité arriver dans PHP — même si d’autres ont fait remarquer que cela demanderait d’écrire plus de code pour les appels de fonctions. En fait, les paramètres nommés aideraient surtout pour les appels de fonctions acceptant un nombre conséquent de paramètres.

Nikita Popov, auteur de la RFC en question, a dressé un rapide résumé de la situation : dans l’ensemble, les principales questions en suspend ont toutes une réponse, et l’implémentation de la fonctionnalité est prête. Par contre, il est nécessaire de passer sur l’ensemble des fonctions exposées par PHP pour s’assurer que leurs définitions de paramètres soient acceptables (qu’ils aient des noms cohérents, en particulier), et de vérifier que la lecture de paramètres fonctionne, partout, pour ces mêmes fonctions internes. Ces deux points demandent énormément de travail et il est peu probable que ce soit terminé d’ici le feature freeze de PHP 5.6.

Philip Sturgeon a rédigé la RFC: Array Of, dont l’idée est d’améliorer le type-hinting de PHP de manière à pouvoir indiquer qu’un tableau d’éléments d’un type donné est attendu. Par exemple :

function test(SplFileObject[] $files) {

Les premiers retours ont semblé indiquer que l’idée en intéressait plus d’un — et le sujet, avec pas loin de 100 mails sur environ une semaine, a été un des plus discutés ce mois-ci sur internals@ ! Notons que cela n’a pas empêché quelques retours assez durs ou soulignant que ce type de fonctionnalité (contrairement à d’autres RFC passées ces derniers mois) peut déjà être implémentée en PHP ou ne colle pas forcément à une partie de la philosophie souple du langage. Une réponse à quelques uns de ces retours a été apportée ici.

Une question qui s’est rapidement posée est de savoir s’il était possible d’indiquer si des éléments du tableau pouvaient être NULL (ce qui pourrait mener à des erreurs lors de parcours), et avec quel type de syntaxe. Bien sûr, l’impact sur les performances est aussi à prendre en compte — mais le serait aussi si les vérifications de types étaient réalisées en espace utilisateur.

En fait, comme l’a souligné Julien Pauli un peu plus loin dans la discussion, cette RFC illustre le fait qu’il manque à PHP une notion de “tableau typé” — qui irait plus loin que la vérification de types lors du passage de paramètres. Au passage, même si cette RFC n’a rien à voir avec ces deux points, quelques uns ont reparlé de type-hinting sur types scalaires et de Generics.

En parallèle, Sara Golemon a posté un récapitulatif de ce que permet et accepte HHVM pour les tableaux typés et les Generics — à la fois en visant à arriver à une syntaxe commune et pour résumer les cas tordus identifiés de leur côté.

Suite à cela, Philip Sturgeon a demandé s’il y avait un intérêt pour les Generics — ce qui pourrait avoir une influence sur la syntaxe de Array Of.

Au passage, notons que ce fil de discussion a encore une fois illustré le fait que le type-hinting et ses éventuelles extensions est toujours un sujet chaud !

Yasuo Ohgaki a rédigé la RFC: Multibyte Char Handling, où il propose d’ajouter de nouvelles fonctions pour gérer des chaînes de caractères en encodages sur plusieurs octets.

Plusieurs approches seraient possible, en fait : ajouter de nouvelles fonctions, se baser sur la locale courante (ce qui semble être une mauvaise solution), ou même ajouter un paramètre supplémentaire encodage comme cela a par exemple été fait pour htmlspecialchars().

Comme l’a souligné Derick Rethans, au lieu d’ajouter encore et encore de nouvelles fonctions (que les développeurs PHP doivent ensuite choisir d’utiliser lorsque c’est nécessaire), une meilleure approche serait sans doute un réel support d’Unicode par PHP — comme visait à le faire PHP 6 il y a quelques années !

Et suite à cette discussion, la RFC: Alternative implementation of mbstring using ICU a aussi été mise à jour.

Anatol Belski a annoncé que les choses avaient suffisamment avancées sur la RFC: 64 bit platform improvements for string length and integer in zval pour que les discussions puissent commencer (il y a eu environ 200 mails échangés sur le sujet ce mois-ci, tout de même !).

Pour essayer de résumer les échanges en quelques mots : l’objectif ici est d’améliorer le support des plate-formes 64 bits par PHP (notamment sous Windows), sans que cela n’ait d’impact sur les plate-formes 32 bits.

Une conséquence non-négligeable est qu’il faudrait repasser sur toutes les extensions existantes pour modifier quelques appels de fonctions (comme zend_parse_parameters() et *printf()) et quelques utilisations de macros. Ceci demanderait quelques heures à quelques jours de travail pour chaque extension. Mais cela représente un risque réel, puisque toutes les extensions, y compris celles développées par des entreprises pour leur besoins internes1 et non rendues publiques, devront être modifiées — et que toutes ne le seront certainement pas au moment de la sortie de PHP 5.6. De ce fait, il pourrait s’agir d’une modification trop importante pour PHP 5.6.

Les votes ont été ouverts en fin de mois ; les résultats seront donc pour le mois prochain. Quelques premières explications sur des votes négatifs ont d’ailleurs insisté sur le trop grand impact de cette modification pour PHP 5.6, et le fait qu’elle trouverait mieux sa place vers une future version majeure.

En parallèle de cette discussion sur les améliorations 64 bits, Anatol Belski a créé la RFC: Removal of dead SAPIs. Comme l’a noté Julien Pauli, ces vieilles SAPI qui datent pour certaines des années 90 et ne sont plus utilisées/maintenues pourraient être supprimées.

Tout juste le premier jour du mois, Daniel Lowrey a annoncé la fin des votes sur la RFC: TLS Peer Verification. Avec 25 votes “pour” et aucun vote “contre”, voici une amélioration de sécurité qui arrivera avec PHP 5.6. Quelques jours après, il a continué sur le sujet, avec la RFC: Improved TLS Defaults qui vient en complément de la précédente.

Dans la foulée, Ondřej Hošek a ouvert les votes sur la RFC: ldap_modify_batch, qui visait à ajouter une nouvelle fonction à l’extension ldap. Avec 5 votes “pour” et 0 vote “contre”, elle est passée et la nouvelle fonction pourrait donc faire partie de PHP 5.4 et versions supérieures.

Sara Golemon a rédigé la RFC: GMP Floating Point Support en extrayant une portion de la RFC: GMP number as PHP number qui a quant à elle été retirée.

La RFC: Argument Unpacking avait été ouverte aux votes à la fin du mois dernier. Avec 32 votes “pour” et 2 votes “contre”, elle est passée. Cette nouveauté, qui arrivera pour PHP 5.6, complémente la RFC: Syntax for variadic functions qui était passée il y a quelques mois.

Daniel Lowrey a commencé à travailler sur une série de modifications visant à permettre un fonctionnement non-bloquant pour ext/pgsql. En parallèle, Yasuo Ohgaki a implémenté le support d’objets de plus de 2 Go (arrivé avec PostgreSQL 9.3).

Yasuo Ohgaki a annoncé la fin des votes sur la RFC: Use default_charset As Default Character Encoding : avec 8 votes “pour” et 1 vote “contre”, elle est passée. Dans la foulée, il a indiqué avoir travaillé sur la RFC: Multibyte Char Handling et souhaiter des commentaires sur le sujet.

Dmitry Stogov a annoncé avoir commencé à travailler sur un possible nouveau gestionnaire de mémoire pour PHP. En l’état, ce prototype ne fonctionne que sous Linux (sur un build de PHP sans information de debug), et semblerait apporter dans les 3% de gain de performances sous Drupal et entre 12% et 15% sur une portion de code très gourmande en construction d’objets.

Sara Golemon a rédigé la RFC: Module API Inspection, qui ajouterait deux options à PHP en ligne de commande, permettant de déterminer la version de modules zend gérée par PHP, ainsi que celle contre laquelle une extension a été compilée. Toutefois, la solution mise en place n’est pas parfaite, et il n’est donc pas certain qu’elle soit validée.

Andrea Faulds a annoncé l’ouverture des votes sur la RFC: Alphanumeric Decrement. Avec 21 votes “contre” et aucun vote “pour”, elle a été rejetée à l’unanimité.

Les votes ont été ouverts sur la RFC: Introduce session options - read_only, unsafe_lock, lazy_write and lazy_destroy. Suite à cela, les discussions sur le sujet sont reparties, et les votes ont été arrêtés, le temps d’apporter quelques mises à jour la RFC.

En toute fin de mois, Gordon Oheim a annoncé l’ouverture des votes sur la RFC: Automatic Property Initialization, qui vise à faciliter l’initialisation de propriétés lors de l’écriture d’un constructeur, à l’aide d’une syntaxe de ce type :

// would assign properties and provide $z as a local variable
public function __construct($this->x, $this->y, $z)
    // do something with $z locally

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

  1. Yahoo aurait de l’ordre de 500 extensions PHP en interne, selon ce mail

Par Pascal MARTIN le lundi 10 février 2014

Cet article est aussi disponible en français.

I’ve been doing a monthly digest of what happens on internals@ for more than a year now, each time in French. Every now and then, some people said it would be nice to have it in English too… So, after last month, here’s my second shot at this!

BTW, here’s the RSS feed of the posts I might write in English.

2014 started by a busy January with 963 messages, which is almost exactly twice the number of mails of the previous month.

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

On January 15, Ferenc Kovacs announced he would soon tag PHP 5.6-alpha1 — this version has been published a few days later, on January 24.

The release of this first alpha version means that (in theory) new RFC cannot be proposed for PHP 5.6 anymore. Julien Pauli answered saying that no RFC will be allowed to be merged (into PHP 5.6) once the beta versions phase has started. The first beta version could be published around mid-march.

Adam Harvey has started working on the documentation page Migrating from PHP 5.5.x to PHP 5.6.x.

Some features have been marked as deprecated when PHP 5.5 was released: the /e modifier for preg_replace(), the ext/mysql extension, … According to the release cycle, those deprecated features should be removed from PHP 5.6 (and/or be moved to PECL, for extensions like ext/mysql).

As quickly noted by Andrea Faulds, we can still find a lot of code that uses mysql_*() functions, and moving the corresponding extension to PECL might cause a fair share of problems. That being said, distributions will still be able to provide this extension. Also, many tutorials (and a few well-known software) still using functions that have been deprecated for several years (or functions for which the documentation explicitly said “do not use this”) is not a reason that should stop PHP from evolving.

As some proposals under discussions would have more impact than those landed with PHP 5.3/4/5, Adam Harvey asked if it wouldn’t be time to start thinking about a new major version of PHP — it’s an idea that’s already been spoken about a few time those last months, actually.

As posted by Julien Pauli, going further than just allowing BC-breaking changes, a new major version would also be a great occasion to do some cleaning-up — afterall, PHP 5.0 did introduce a new version of Zend Engine. Ferenc Kovacs noted, as he already said a couple of months ago, that there currently is no defined process about the creation of a new major version.

In order to facilitate the switch to this future version, and to avoid it taking more than 5 years as it did for PHP 5, an idea might be to use the FIG to synchronize a step-up in the PHP version required by the most commonly used frameworks.

Rasmus Lerdorf insisted on the fact that, in his opinion, PHP should remain a pragmatic language, oriented towards the web (the corresponding needs have evolved), loosely typed, and which caters to the skill-levels and platforms of a wide range of users. Unicode support would be a must-have, performances should not be forgotten, and PDO could use some attention. All this is less sexy than new features, but we should not forget that these points meet real needs. Julien Pauli answered with a few ideas he has, such as a threaded VM or enhancements and optimisations at its level.

Andrea Faulds continued with a subject about case-sensibility in PHP: wouldn’t a future major version be an occasion to make things a little more uniform?

In parallel, Rasmus Lerdorf answered on a thread about what some call inconsistency in functions names in PHP and the parameters (and their order) they expect: since the beginning, PHP has been a wrapper for dozens (hundreds now) of libraries. These functions are not specific to PHP: they are known by a great number of developers, not because we use PHP, but because we live in a world written in C — and as soon as we venture outside of the world of PHP and scripting-languages, we fell into that other world. Still, as answered by Larry Garfield, today, only a small number of PHP developers also know C or POSIX… Actually, C is probably the second language of only a very small number of PHP developers. Following this discussion, the skeleton of a new RFC has been set up: RFC: Use alias to provide both legacy and consistent names.

On another side, Pierre Joye started a third thread about PHP 6, where he noted it is important to think about the impact some changes might have in terms of adoption of a future version of the language (an idea that’s been talked about a few times is to avoid getting in the same kind of situation than Python 2 and Python 3).

As people in the community talk more and more about HHVM, zhifeng hu asked if it would be possible to include it in PHP’s code.

Pierre Joye quickly answered that, even if it seems interesting on several counts, there were reasons to not consider this idea for now: HHVM is controlled by a single entreprise, signing a CLA is required in order to be able to participate to its development, and it’s not really portable (it requires GCC). In addition, as noted by Andrea Faulds, HHVM is not a complete implementation of PHP’s features — especially, as answered by Sara Golemon, when it comes to extensions bundled or provided through PECL.

In fact, considering the current state of PHP and HHVM, this proposal could have come a bit in advance — like a year or two.

Sara Golemon has written the RFC: __debugInfo(). It’s goal is to expose debugging informations (already known internally) to user-space — by adding a new magic method called __debugInfo(). This proposal would allow to customize debug output.

Amongst the reactions, some noted that a name such as __dump() might be more explicit for PHP developers who don’t know how the engine works internally, and others remarked this feature should also be added to the Reflection API. It should also be noted that, with such a feature, var_dump() might no longer always tell the truth.

Kevin Ingwersen has revived a thread about the RFC: Named Parameters, written in September 2013 and which had not been discussed much those last weeks.

Many would like to see this kind of feature in PHP — even if others noted we’d have to write more code for function-calls. Actually, named-parameters would mostly help for functions that accept a large number of parameters.

Nikita Popov, author of that RFC, did a quick summary: generally speaking, the main questions all have an answer, and the implementation of this feature is ready. Still, it is required to have a look on all functions exposed by PHP to make sure their parameters definitions are correct (for example, they must have coherent names), and to make sure that parameters parsing works, everywhere, for those same internal functions. Those two points require a great deal of work, and chances are low it’ll be done before PHP 5.6’s feature freeze.

Philip Sturgeon has written the RFC: Array Of, which intends to enhance PHP’s type-hinting, to allow a function to specify it expects an array of elements that are all of a given type. For example:

function test(SplFileObject[] $files) {

The firsts reactions seemed to show this idea interested some people — and the subject, with about 100 mails in one week, has been one of the most discussed ones on internals@ this month! It didn’t prevent a few hard reactions or ones underlining that this kind of feature (contrarily to other RFCs that passed in the last months) can already be implemented in PHP or doesn’t quite fit with a part of the language’s philosophy. An answer to some of these opinions has been posted here.

A question that’s been asked rapidly is if it would be possible to specify whether some of the array’s elements might be NULL (which could lead to errors), and with what kind of syntax. Of course, impact on performances should not be forgotten — but would also exist if that kind of verifications was done in user-space.

As a matter of fact, as noted by Julien Pauli a bit later in the conversation, this RFC might highlight the fact PHP lacks a notion of “typed array” — that would go farther than type-checking when passed as a parameter. Even if this RFC was not related to these points, some talked about type-hinting for scalar types and about Generics.

In parallel, Sara Golemon posted a summary of what HHVM accepts for typed-arrays and Generics — the goal being to reach a common syntax and to illustrate a few specific cases they met on their side.

Following this, Philip Sturgeon asked if there was some interest for Generics — which might have some influence on the syntax of Array Of.

By the way, it seems this thread once again highlighted the fact that type-hinting and its possible extensions is still quite a hot matter!

Yasuo Ohgaki has written the RFC: Multibyte Char Handling, in which he proposes to add several new functions to deal with strings using multi-bytes encodings.

Several approaches could be possible, actually: adding some new functions, using the current locale (which seems to be a bad idea), or even adding some kind of encoding parameters to existing functions, as it’s been done for htmlspecialchars().

As noted by Derick Rethans, instead of yet again adding new functions (that PHP developers will need to use when necessary), a better solution would be a real support of Unicode by PHP — like what was planned for PHP 6 several years ago!

Following this discussion, the RFC: Alternative implementation of mbstring using ICU has also been updated.

Anatol Belski announced discussions could begin on RFC: 64 bit platform improvements for string length and integer in zval, as the implementation was going well (there have been around 200 mails on that matter this month!).

Trying to summarize things in a few words: the objective here is to enhance support of 64 bits platforms by PHP (especially under Windows), and this should not have any impact on existing 32 bits platforms.

A non-negligible consequence is that it would be necessary to update all existing extensions to change some function calls (like zend_parse_parameters() and *printf()) and some macro usages. This would require between a few hours and a few days of work for each extension. But there is a real risk, as all extensions, including those developed by companies1 for their internal needs and not made public would have to be updated — and it’s quite probable not all of them will be before PHP 5.6 is released. Because of this, it might be a change too impacting for PHP 5.6.

Votes have been opened at the end of the month; which means results are to be expected for next month. Some first explanations about negative votes insisted on the too great impact of this change for PHP 5.6, and the fact it might be better suited for a future major version.

Following this discussion on 64 bits enhancements, Anatol Belski created the RFC: Removal of dead SAPIs. As Julien Pauli posted, these old SAPI which, for some, date back from the 90s and are not used nor maintained anymore, could be removed.

Right on the first day of this month, Daniel Lowrey annouced the votes had ended on RFC: TLS Peer Verification. With 25 votes “for” and no vote “against”, here’s a security enhancement that will come with PHP 5.6. A few days later, he continued on that subject, with the new RFC: Improved TLS Defaults that complements the previous one.

Ondřej Hošek opened votes on the RFC: ldap_modify_batch, which meant to add a new function to the ldap extension. With 5 votes “for” and 0 vote “against”, it passed and the new function should make it to PHP >= 5.4.

Sara Golemon wrote the RFC: GMP Floating Point Support, by extracting a part of RFC: GMP number as PHP number which has been retired.

The RFC: Argument Unpacking had been submitted to votes at the end of last month. With 32 votes “for” et 2 votes “against”, it passed. This new feature, planned for PHP 5.6, complements RFC: Syntax for variadic functions which passed a few months ago.

Daniel Lowrey has started working on allowing a non-blocking mode for ext/pgsql. About that extension, Yasuo Ohgaki has implemented support for objects bigger than 2 GB (which landed with PostgreSQL 9.3).

Yasuo Ohgaki announced the end of the voting period for RFC: Use default_charset As Default Character Encoding: with 8 votes “for” et 1 vote “against”, it passed. He also indicated working of the RFC: Multibyte Char Handling and that he needed comments on that one.

Dmitry Stogov said he started working on a possible new memory manager for PHP. For now, his prototype only works on Linux (on a non-debug build of PHP), and it seems it could bring a 3% performance gain for Drupal and between 12% and 15% on a portion of code that does a lot of objects constructions.

Sara Golemon wrote the RFC: Module API Inspection, which would add two options to PHP’s command-line, allowing one to determine the version of zend modules accepted by PHP, and the version against which an extension has been compiled. Still, the implemented solution isn’t perfect, and it is possible it might not be accepted.

Andrea Faulds opened votes on RFC: Alphanumeric Decrement. With 21 votes “against” and no vote “for”, its has been unanimously rejected.

The voting period has begun on the RFC: Introduce session options - read_only, unsafe_lock, lazy_write and lazy_destroy. Following this, discussions on the subjects have re-started, and votes have been canceled, as the RFC will be updated.

Finally, right at the end of the month, Gordon Oheim opened votes on RFC: Automatic Property Initialization, which aims to facilitate properties’ initialization when we are writing a constructor, using a syntax like this:

// would assign properties and provide $z as a local variable
public function __construct($this->x, $this->y, $z)
    // do something with $z locally

We’ll see next month how things end up ;-)

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. It seems Yahoo might have about 500 PHP extensions PHP internally, according to this mail

Par Pascal MARTIN le lundi 6 janvier 2014 1 commentaire

Cet article est aussi disponible en français.

I’ve been doing a monthly digest of what happens on internals@ for more than a year now, each time in French. Every now and then, some people said it would be nice to have it in English too… So, here’s my first shot at this!

2013 ended with 489 messages in December, which is just a little bit more than the month before [fr].

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

Ferenc Kovacs, RM of PHP 5.6, announced a release timetable for this future version. If things go as planned, the steps leading to the release of PHP 5.6 should be:

  • 1st alpha version in January 2014 (no more new RFC proposal from this point on),
  • 1st beta version in March 2014 (feature-freeze),
  • 1st RC version in May 2014,
  • and release of the first stable version, PHP 5.6.0, in the middle of June 2014.

For now, the features corresponding to the following RFC have been merged:

This list of RFC represents the biggest changes currently planned for PHP 5.6. There could also be some smaller changes here and there, and we still have a few months before feature-freeze ;-)

It’s one of the threads with the greatest number of mails this month1: Nikita Popov announced he had opened votes on the RFC: Exceptions in the engine — the idea of which being to replace as many fatal errors as possible by exceptions, in PHP itself.

For the curious ones: this mail lists some of the errors that cannot be converted to exceptions, and some of those that can easily be.

From the beginning, Nikita fixed the following rule:

If you are in favor of the proposal in general, but want to have it in PHP 6 rather than PHP 5.6, then vote “No” here.
If it fails now, someone can revive this once the time for PHP 6 has come.

Integrating this modification to PHP 5.6 has been declined, with 24 votes “for” and 21 votes “against” (this was a modification impacting the language; which means it needed 2/3 “yes” to pass).

Still, considering that more than half the votes were “in favor” and the discussions that took place lately about this idea, I have no doubt it will come back when we are talking about PHP 6 — maybe it was just a little bit too much of a change to be part of a minor version.

We can feel that PHP 5.6 is getting near, with several RFC going through the voting process one after the other:

Votes have been opened on the RFC: phpdbg at the beginning of the month. With 40 votes “for” and 0 votes “against”, it passed: phpdbg will be bundled with PHP 5.6!

The RFC: Slim POST data has too been opened to votes. With 17 votes “for” and 0 votes “against”, it passed for PHP 5.6.

Daniel Lowrey announced votes were opened on the RFC: TLS Peer Verification. With 25 votes “for” and 0 votes “against”, this one passed too: by default, PHP 5.6 should include this verification, providing better security.

The RFC: Power Operator, about which I wrote about last month [fr] has too been opened to votes — before they got reset following an update of the RFC. More or less in parallel, many discussions have still taken place, especially about the associativity and the precedence of this new operator. The voting period ends at the beginning of January 2014, but things seem to be going well for now.

Nikita Popov opened the votes on the RFC: Argument Unpacking. Here too, things seem to be going quite well for an integration to PHP 5.6, and final results will come in a few days.

Rouven Weßling wrote the RFC: Timing attack safe string comparison function, the idea behind it being to ease the fight against timing attacks.

This proposal received some interest, even if the first suggested name did not convince, something like strcmp_secure() possibly being better suitedor not.

A part of the discussion was about the fact that such a function can already be implemented in PHP… But an implementation bundled with PHP might anwer a common need, and highlight the fact that string comparisons, to be secure, require a few precautions. Actually, this was part of the idea behind the addition of password_hash() to PHP 5.5.

Andrea Faulds noted its is possible to increment a string with the ++ operator, but that we cannot use -- for the inverse manipulation. As a consequence, he suggested this second behavior could be implemented.

A question that has quickly been asked is how "a" should be decremented: "0" ? or "-1" as in Perl?
Another idea would be to decrement "a" to an empty string, which could itself be re-incremented to "a". But it would not be compatible with the current behavior.

Following this discussion, Andrea Faulds has created the RFC: Alphanumeric Decrement.

Yasuo Ohgaki posted that a 0 GMP object is not considered as being empty(). He also noted that is_scalar() returns false for a GMP object — same thing for is_numeric(), btw.

The idea behind those notes was that GMP objects will work a bit like numbers with PHP >= 5.6 (because of the mechanism provided by PHP 5.6 to allow operator overloading for classes declared by extensions), and those points could be surprising for end-users.

Following those posts, Yasuo Ohgaki announced he had began working on the RFC: GMP number.

A few months ago, an optimization for some cases caused a performance-regression for strtr() in several other cases. This month, Zeev Suraski noted it might be a good idea to cancel that modification (which shouldn’t have been deployed, considering its impact): as it sometimes takes months to win a few percents on performances, it’s a bit sad having introduced this regression and only taking care of it six months later.

Still, as noted by Pierre Joye, going one step forward / one step backward is not a real solution, especially considering this modification only impacted the performance of a single function.

Actually, as suggested by Hannes Magnusson, this kind of optimization (which caused, here, a regression in some cases) maybe shouldn’t be done in a minor version…

Ondřej Hošek wrote the RFC: ldap_modify_batch. There have not been many comments on that matter — which is often a good sign (or, it shows the ldap extension is not used much).

Sara Golemon noticed base-conversions done by PHP are sometimes a bit surprising, and wrote the RFC: Fix base_convert() and related PHP lib functions in which she proposed a couple of ideas of solutions.

Stefan Neufeind talked about his idea of a new function called get_class_constants(), based on the model of get_class_methods() and get_class_vars(). Some have answered that, as the Reflection already provides a way to access these informations, it is probably not necessary to add a new dedicated function to PHP.

Following a discussion started in october, Yasuo Ohgaki wrote about the RFC: Use default_charset As Default Character Encoding, and it has been opened to votes.

Anatol Belski did a report on the progress of enhancements for 64 bits platforms — work that’s been going on for a few months.

Yasuo Ohgaki wrote the RFC: Introduce session.lock, session.lazy_write and session.lazy_destory — but his propositions didn’t cause much discussion for now; maybe some end of year effect?

And, to finish this digest, Lior Kaplan has kept on posting his reports about pull-requests for PHP: on December 5 and on December 20

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. Well, that’s depending on how one counts: other subjects have seen more discussions, but split in several threads… 

Par Pascal MARTIN le lundi 6 janvier 2014 3 commentaires

For the first time, this post is also available in english.

L’année 2013 se termine avec un mois de décembre à 489 messages, soit un tout petit peu plus que le mois précédent — et nous voici début 2014, ce qui me donne l’occasion de vous souhaiter une très bonne et heureuse année !

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

Pour commencer, Ferenc Kovacs, RM de PHP 5.6, a annoncé un plan de sortie pour cette future version. Si celui-ci est respecté, les différentes étapes de la publication de PHP 5.6 pourraient être :

  • 1ère version alpha en janvier 2014 (plus de proposition de nouvelle RFC pour PHP 5.6 à partir de ce moment),
  • 1ère version bêta en mars 2014 (feature-freeze),
  • 1ère version RC en mai 2014,
  • et sortie de la première version stable, PHP 5.6.0, mi-juin 2014.

En l’état actuel, les fonctionnalités correspondant aux RFC suivantes ont été mergées :

Cette liste de RFC regroupe les plus grosses nouveautés actuellement prévues pour PHP 5.6. Elles peuvent s’accompagner de petits changements ici et là, et il reste encore quelques mois avant le feature-freeze ;-)

C’est un des fils de discussion qui a vu le plus d’échanges ce mois-ci1 : Nikita Popov a annoncé avoir ouvert aux votes la RFC: Exceptions in the engine, dont l’idée était de remplacer autant de levée d’erreurs Fatales que possibles par des remontées d’exceptions, au sein de PHP lui-même.

Pour les plus curieux : ce mail liste une partie des erreurs qu’il ne serait pas possible de convertir en exceptions, ainsi qu’une partie de celles qui peuvent l’être assez facilement.

Dès le départ, Nikita a annoncé la règle suivante :

Si vous êtes en faveur de la proposition en général, mais voulez l’avoir pour PHP 6 plutôt que pour PHP 5.6, alors votez “Non” ici.
Si cette RFC ne passe pas aujourd’hui pour PHP 5.6, quelqu’un pourra la ramener à la vie une fois que sera venu le moment de penser à PHP 6.

L’intégration de cette modification à PHP 5.6 a été rejetée, avec 24 votes “pour” et 21 votes “contre” (il s’agissait d’une modification impactant le langage ; il aurait donc fallu 2/3 de “oui” pour qu’elle passe).

Considérant que plus de la moitié des votes étaient “pour” et les discussions qui ont eu lieu ces derniers temps autour de cette modification, je n’ai aucun doute sur le fait qu’elle reviendra sur le devant de la scène lorsque nous parlerons de PHP 6 — elle était peut-être juste un peu trop importante pour être intégrée à une version mineure.

On sent l’approche de PHP 5.6, avec plusieurs RFC qui sont ce mois-ci passées en phase de vote les unes après les autres :

La RFC RFC: phpdbg a été ouverte aux votes en début de mois. Avec 40 votes pour, et 0 vote contre, elle est passée : phpdbg sera intégré à PHP 5.6 !

La RFC RFC: Slim POST data a elle aussi été ouverte aux votes. Avec 17 votes pour et 0 votes contre, elle est passée pour PHP 5.6.

Daniel Lowrey a annoncé l’ouverture des votes sur la RFC: TLS Peer Verification. Avec 25 votes “pour” et 0 vote “contre”, celle-ci aussi est passée : par défaut, PHP 5.6 devrait donc intégrer cette vérification, améliorant ainsi la sécurité.

La RFC: Power Operator, dont j’ai déjà parlé le mois dernier a elle aussi été ouverte aux votes — avant que ceux-ci ne soient réinitialisés suite à une mise à jour de la RFC. Plus ou moins en parallèle, de nombreux échanges ont encore eu lieu, tout particulièrement autour de l’associativité et de la précédence de ce nouvel opérateur. La période de vote se termine début janvier 2014, mais les choses semblent pour l’instant bien parties.

Nikita Popov a ouvert les votes sur la RFC: Argument Unpacking. Ici aussi, ça semble plutôt bien parti pour une inclusion à PHP 5.6, mais résultats dans quelques jours.

Rouven Weßling a proposé la RFC: Timing attack safe string comparison function, l’idée étant de faciliter la lutte contre les attaques temporelles.

L’idée a semblé en intéresser plus d’un, même si le nom initialement proposé n’a pas fait l’unanimité, quelque chose comme strcmp_secure() semblant plus adaptéou pas.

Une partie de la discussion a porté sur le fait qu’une telle fonction peut déjà être implémentée en PHP… Mais qu’une implémentation fournie avec PHP permettrait peut-être de répondre à un besoin commun et mettrait en évidence le fait qu’une comparaison de chaînes, pour être sécurisée, doit être faite en prenant quelques précautions. C’était un peu l’idée derrière l’ajout de password_hash() à PHP 5.5, d’ailleurs.

Andrea Faulds a noté qu’il était actuellement possible d’incrémenter une chaîne de caractères avec l’opérateur ++, mais qu’il n’était pas possible d’utiliser -- pour effectuer l’opération inverse. Il a donc proposé d’implémenter ce second comportement.

La question qui s’est rapidement posée est de savoir comment "a" devrait être décrémenté : "0" ? ou "-1" comme en Perl ?
Une autre idée serait de décrémenter "a" vers une chaîne vide, qui pourrait elle-même être incrémentée vers "a". Mais cela ne collerait pas avec le comportement actuel.

Suite à cette discussion, Andrea Faulds a créé la RFC: Alphanumeric Decrement.

Yasuo Ohgaki a remarqué qu’un object GMP 0 n’était pas considéré comme empty(). Il a aussi noté que is_scalar() retournait false pour un objet GMP — même chose pour is_numeric(), d’ailleurs.

L’idée derrière ces remarques était que les objets GMP vont fonctionner un peu comme des nombres à partir de PHP 5.6 (avec le mécanisme de surcharge des opérateurs que fournit PHP 5.6 pour les classes déclarées depuis des extensions), et que ces points pouvaient être surprenant pour les utilisateurs.

Suite à cela, Yasuo Ohgaki a annoncé avoir commencé à travailler sur la RFC: GMP number.

Il y a quelques mois de cela, une optimisation pour certains cas avait entraîné une forte dégradation des performances de strtr() pour d’autres. Ce mois-ci, Zeev Suraski a fait remarquer qu’il pourrait être bon d’annuler cette modification (qui n’aurait même jamais dû être déployée, vu l’impact) : considérant qu’il faut parfois des mois pour gagner quelques pourcents au niveau des performances, il est un peu dommage d’avoir introduit cette perte et de ne s’en soucier que six mois après.

Toutefois, comme l’a souligné Pierre Joye, jouer à un pas en avant / un pas en arrière n’est pas une réelle solution, d’autant plus que la modification en question n’impacte les performances que d’une seule fonction.

En fait, comme l’a suggéré Hannes Magnusson, ce type d’optimisation (qui s’est ici traduite par une régression dans certains cas) ne devrait peut-être pas avoir sa place dans une version mineure…

Ondřej Hošek a rédigé la RFC: ldap_modify_batch. Peu de retours sur le sujet — ce qui est souvent bon signe (ou alors, cela montre que l’extension ldap n’est pas tellement utilisée).

Sara Golemon a remarqué que les conversions de bases effectuées par PHP étaient parfois surprenantes et a rédigé la RFC: Fix base_convert() and related PHP lib functions où elle a proposé plusieurs pistes de solutions.

Stefan Neufeind a évoqué l’idée d’une nouvelle fonction nommée get_class_constants(), un peu sur le modèle de get_class_methods() et get_class_vars(). Plusieurs ont répondu que, puisque la Reflection permettait déjà d’accéder à ces informations, il ne semblait pas utile d’ajouter à PHP une nouvelle fonction dédiée.

Faisant suite à une discussion qui remontait à octobre, Yasuo Ohgaki a relancé la RFC: Use default_charset As Default Character Encoding, et elle a été ouverte aux votes.

Anatol Belski a dressé un rapport sur l’avancement d’améliorations concernant les plate-formes 64bits, travail en cours depuis quelques mois et qui avance petit à petit.

Yasuo Ohgaki a rédigé la RFC: Introduce session.lock, session.lazy_write and session.lazy_destory — sans que ses propositions n’entrainent pour l’instant de réelle discusion ; peut-être l’effet fin d’année ?

Et, pour finir, Lior Kaplan a continué à poster ses rapports des PR effectuées sur PHP : le 5 décembre, le 20 décembre

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. Certes, si on compte un peu mieux, certains sujets ont vu plus d’échanges, mais répartis sur plusieurs fils de discussions… 

Par Pascal MARTIN le mercredi 4 décembre 2013 8 commentaires

J’ai posté mon premier dépilage d’@internals tout début décembre 2012, en parlant de ce qu’il s’était passé durant le mois de novembre… Cette série d’articles a donc tout juste un an !

Un an après, ce mois de novembre 2013 a poursuivi la tendance à la baisse du nombre de mails entamée le mois dernier, avec 468 messages.

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

Continuant à avancer dans le processus de release de la future version de PHP, Ferenc Kovacs a annoncé la création de la branche git correspondant à PHP 5.6.

La todo-list pour PHP 5.6 a été initialisée par Julien Pauli, qui soulignait en parallèle que PHP 5.6 était en retard par rapport au planning de sortie de PHP 5.5 l’an dernier, la première version alpha n’ayant pas encore été publiée1.

La RFC: Constant Scalar Expressions initialement rédigée par Anthony Ferrara et ré-ouverte par Andrea Faulds le mois dernier correspondait à une idée intéressante, mais que certains trouvaient incomplète, car elle ne permettait pas d’utiliser des constantes dans les définitions.

Pour aller plus loin et résoudre ce point, Bob Weinand a proposé une nouvelle version : RFC: Constant Scalar Expressions. Cette version permettrait d’utiliser des syntaxes de ce type pour déclarer des propriété, en travaillant avec des expressions, incluant éventuellement des constantes :

class Bar {
    public $foo = 1 + 1;
    public $bar = [
        1 + 1,
        1 << 2,
        Foo::BAZ => "foo "."bar"
    public $baseDir = __DIR__ . "/base";

L’idée semblant être appréciée, la RFC a été ouverte aux votes ; et une semaine après, elle est passée, avec 16 votes pour et 2 votes contre. Une nouvelle fonctionnalité pour PHP 5.6, donc !

Tjerk Meesters a annoncé avoir travaillé sur la mise en place d’un nouvel opérateur “** (qui existe déjà en Python, par exemple) qui agirait comme la fonction pow(). L’idée d’ajouter un opérateur puissance à PHP a semblé en intéresser plusieurs, même si d’autres ont noté qu’il était plus difficile, notamment pour un débutant, de chercher de la documentation sur un opérateur que pour une fonction.

La question de la précédence de cet opérateur s’est rapidement posée : il convient de déterminer ce qu’il doit se passer pour des opérations comme -3 ** 2 ou 2 ** 3 ** 2. Il faudra aussi s’assurer que ce nouvel opérateur est intégré au mécanisme de surcharge d’opérateurs ajouté récemment à PHP, et utilisé à partir de PHP 5.6 pour l’extension GMP. Par soucis de cohérence, l’ajout d’un opérateur **= a également été proposé par Derick Rethans.

Une autre solution évoquée par Pierre Joye, qui éviterait l’ajout d’un opérateur et les questions à propos de sa précédence tout en bénéficiant des mêmes avantages en termes d’optimisation par rapport à l’actuelle fonction pow(), serait de transformer celle-ci en un opérateur — cette idée a déjà été mise en place pour, par exemple, isset(), qui n’est techniquement pas une fonction. Par contre, il ne serait probablement plus possible d’utiliser pow() comme fonction de rappel…

Après quelques jours de discussions, Tjerk Meesters a annoncé avoir rédigé la RFC: Power Operator — les échanges s’étant alors poursuivis sur ce sujet.

Avec 70 mails répartis sur les deux fils de discussions, cette idée de nouvel opérateur “**” a été la plus discutée du mois, et je suis curieux de voir son évolution d’ici le feature-freeze de PHP 5.6 !

Cela faisait quelques temps qu’il travaillait sur ce projet. Joe Watkins a annoncé avoir rédigé la RFC: phpdbg, qui vise à intégrer la plate-forme de debugging phpdbg à PHP.

Parmi ceux qui ont compris ce que représentait cet outil, les retours ont été fort positifs : l’inclusion d’un outil de ce type rendrait PHP plus pratique pour de nombreux développeurs.

Toutefois, les échanges ont montré qu’il était nécessaire que les différences par rapport à d’autres solutions, comme Xdebug, soient plus clairement expliquées — et la RFC a été enrichie en conséquence.

Chris London a noté que la syntaxe elvis de l’opérateur ternaire introduite avec PHP 5.3 souffrait d’un inconvénient : elle entraîne une levée de notice en cas de variable inexistante. Il proposait donc que l’écriture suivante :

$foo = $foo ?: 'default';

devienne équivalente à celle-ci :

$foo = isset($foo) && $foo ? $foo : 'default';

En fait, cette idée n’est pas sans rappeler la proposition, qui remonte à il y a déjà pas mal d’années, de ifsetor()… D’autant plus que la levée de notice est, finalement, une sécurité.

Une idée alternative serait d’introduire un nouvel opérateur ternaire — comme le @: proposé par Mats Lindh — d’autant plus qu’il n’est pas réellement envisageable de modifier le comportement de ?: plusieurs années après sa sortie. Une autre proposition de Philip Sturgeon serait d’écrire ceci :

$foo ||= 'default';

Ou alors, $foo ?= 'default'; qui semble convenir à plusieurs… Bref, plusieurs propositions, mais aucune qui se détache réellement du lot pour l’instant — si tant est que le besoin soit réel, ce que nous verrons (ou pas) sur les prochains mois.

Nikita Popov a fait remarquer que l’idée de ne pas casser la compatibilité antérieure telle qu’elle est formulée dans la RFC: Release Process pouvait parfois être quelque peu contre-productive, chaque changement allant quasi-nécessairement de paire avec… un changement au niveau de la compatibilité2. Sa proposition serait de ne plus se limiter à “ça casse la retro-compatibilité, donc non”, et de passer à “ça modifie quelque chose au niveau de la compatibilité, au point de … et sommes-nous d’accord avec cela ?”.

Une des réponses qui a été formulée est que cette promesse de retro-compatibilité n’est déjà plus tellement vraie aujourd’hui. Néanmoins, comme l’a souligné Pierre Joye, cette règle est avant-tout là pour faciliter les montées de versions pour les utilisateurs. En même temps, est-ce que publier une version majeure tous les 8 à 10 ans est toujours acceptable, et ne constitue pas déjà un frein au progrès considérable ?

La réponse de Ferenc Kovacs, considérant son rôle de RM pour PHP 5.6, est intéressante — et montre à quel point il est difficile de trouver un juste milieu, en particulier pour un projet Open-Source comme PHP, qui n’a pas un “dictateur” à sa tête. Comme souligné par Julien Pauli, co-RM de PHP 5.5 et 5.6, il faudrait peut-être commencer à planifier des sorties de versions majeures, et ne plus se concentrer, comme c’est le cas depuis quelques années, sur les versions mineures — et l’idée d’une prochaine version majeure d’ici à trois ans pourrait être une piste.

Suite à des échanges durant depuis quelques temps, Michael Wallner a annoncé avoir rédigé la RFC: Slim POST data, qui vise, à terme, à supprimer la variable HTTP_RAW_POST_DATA — et, en conséquence, à un gain de mémoire.

La rétro-compatibilité étant potentiellement impactée par ce type de modification, Ferenc Kovacs a proposé un plan qui pourrait aider cette fonctionnalité à arriver prochainement, sans pour autant impacter l’existant de manière trop négative.

A suivre le mois prochain, potentiellement, donc.

PHP supporte depuis sa version 5.3 des sections [HOST] et [PATH] dans son fichier de configuration php.ini. Richard Quadling a proposé d’ajouter une section [SAPI=xxx] qui se comporterait de la même manière, mais permettant de spécifier des directives de configuration par SAPI (typiquement, une directive de configuration pourrait avoir une valeur donnée pour PHP exécuté en CLI, une seconde pour PHP en tant que module Apache, une troisième pour php-fpm, …).

Aujourd’hui, nous avons tendance à utiliser un fichier php.ini par SAPI : /etc/php5/apache2/php.ini, /etc/php5/cli/php.ini, /etc/php5/fpm/php.ini, … Cette proposition permettrait de faciliter la mutualisation du plus gros des directives et d’éviter leur duplication.

En dehors de quelques intervenants travaillant sur le packaging de PHP, l’idée n’a pas tellement attiré l’attention, cela dit.

Nikita Nefedov a proposé d’ajouter un troisième paramètre optionnel à array_unique(), afin de permettre de spécifier un callable destiné à comparer les éléments.

Pour garder trace des comportements parfois étranges de PHP lorsqu’il s’agit de comparaisons et de conversions, Yasuo Ohgaki a créé la RFC: Existing comparison and conversion behaviors to discuss/document.

Oleg Poludnenko a évoqué l’idée (étrange ?) de permettre aux méthodes de classes enfants de spécifier des nombres et types de paramètres différents de ceux attendus par la même méthode de la classe parente — voir ce gist pour un exemple de code.

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. PHP 5.5 étant elle-même sortie quelque peu en retard, notamment du fait de l’inclusion de ext/opcache, le “retard” de la phase alpha de PHP 5.6 ne me semble pas encore inquétant

  2. Je me permet de prendre quelques libertés au niveau de l’interprétation et de la formulation ;-)