Ce mois-ci sur internals@php - Décembre 2013

le - Lien permanent 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… 

Vous avez apprécié cet article ? Faites le savoir !

Commentaires

1. Par Guillaume le 2014-01-06 10:18
Guillaume

Encore merci pour cet article!

J’avais l’objectif de pousser la version 5.5 dans mon entreprise le plus vite possible mais il semblerait que je puisse mettre un peu d’eau dans mon vin et préparer l’arrivée de la 5.6 en Juin. Cela laisse plus de temps aux équipes pour se préparer et on pourra même envisager une branche sur une version beta (voir RC) en attendant.

Savez-vous si en général, ces délais sont tenus?

Petit bonus, j’ai appris que $x++ avec “a” vaut “b” x)

2. Par Pascal MARTIN le 2014-01-06 20:11
Pascal MARTIN

@Guillaume > je serais tenté de dire que PHP suit un peu la logique du “ça sort quand c’est prêt”.

Avec un cycle de releases qui vise à une version mineure par an, il y a peu de chance de se trouver avec un décalage de six mois.

Par contre, en cas de problème (genre un gros bug ; ou plein de petits constatés pendant les phases alpha/beta/RC, qui entrainent plus de versions de test qu’actuellement prévu), ça peut décaler un peu. Mais ce décalage serait dû à de bonnes raisons. A nous de tester efficacement dès les versions alpha, pour détecter les éventuels bugs et régressions au plus tôt, donc !

La sortie de PHP 5.5, l’an dernier, a été pas mal décalée (je ne sais plus de combien exactement ; je dirais quelque chose comme deux mois) pour inclure ext/opcache. Mais il n’y a pas une “volonté” de reproduire ce schéma — et en cas d’arrivée tardive d’une idée du même type, il se peut que l’équipe qui gère les releases se souvienne de ce qu’il s’est passé l’an dernier et choisisse de repousser à la version suivante (ou pas).

En tout cas, rien n’empêche de passer dès maintenant à PHP 5.5, ne serait-ce que sur les environnements de développement d’une partie des développeurs de votre équipe ou sur une partie des serveurs d’intégration, pour s’assurer que vos applications fonctionnent en 5.5 : tout problème rencontré avec PHP 5.5 et corrigé pour cette version a de bonnes chances d’être un problème de moins à corriger lors de la migration vers 5.6.

D’ailleurs, c’est comme ça que se sont faites les migrations 5.2 -> 5.3 puis 5.3 -> 5.4 auxquelles j’ai participé :

  • d’abord un développeur de chaque équipe, volontaire pour migrer et corriger le plus gros des problèmes (et faire passer tous les tests),
  • puis un serveur d’intégration qui migre pour vérifier régulièrement que tous les tests continuent à passer à la fois en 5.x et en 5.x+1,
  • puis les autres développeurs qui migrent petit à petit,
  • puis le plus gros des serveurs d’intégration (en en conservant un ou deux en 5.x, puisque la prod est encore en 5.5),
  • puis les serveurs de production,
  • et enfin, les derniers serveurs d’intégration.
3. Par Guillaume le 2014-01-07 09:46
Guillaume

Merci pour la réponse et le retour d’expérience. Ici le message pour la migration est clair en effet, si une équipe migre en PHP 5.5, tout le monde migre! A nous donc d’organiser cela correctement.

Toutefois, j’ose espérer que le travail de migration n’est pas trop élevé. Nous allons passé de 5.3 à 5.5. Du peu que j’ai pu voir, nous ne devrions pas avoir trop de problèmes, qui plus est, les bénéfices sont plus qu’évidents à tout point de vue. Donc en effet, autant passer sous 5.5 le plus vite possible, ça ne fera que simplifier le passage futur à 5.6.

Encore une fois, merci pour tout :)

Ce post n'est pas ouvert aux nouveaux commentaires (probablement parce qu'il a été publié il y a longtemps).