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

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

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 :

• Importing namespaced functions
• Constant Scalar Expressions (with constants)
• Internal operator overloading and GMP improvements
• Remove calls from incompatible context
• Dedicated syntax for variadic functions
• Crypt() function salt
• phpdbg

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-ci¹ : 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.