Et une fois n'est pas coutume, je ne vais pas ménager le suspense et je vais commencer par parler des surprises immédiatement.

La première est que le support du format d'image webp est déjà supporté par la version du trunk de PHP via GD, grâce à Pierre Joye qui en a réalisé l'intégration.

Pour ceux qui ne le saurait pas déjà, webp est un format de fichier présenté récemment par Google permettant la compression d'image avec une perte de qualité, ce qui le pose en concurrent direct du format jpeg.

Et au passage, je souligne que Pierre est un employé de Microsoft qui participe au développement de PHP, ce qui prouve son indépendance d'esprit.

La seconde surprise concerne intl, l'extension d'internationalisation de PHP, qui supporte maintenant les transformations, via la classe \transliterator.

En très résumé, cette nouvelle fonctionnalité permet de traduire un alphabet dans un autre, et il sera donc possible à l'avenir de transformer un mot écrit en katakanas, comme キャンパス, en son équivalent latin, par exemple, à savoir comme vous l'aviez bien sur deviné kyanpasu.

Attention, comme vous pouvez le constater avec l'exemple ci-dessus, il ne s'agit aucunement de traduction, et si vous en doutez encore, je vous invite à jouer avec la démonstration technique relative aux transformations de la bibliothèque ICU, sur laquelle est basée intl.

Unicode fait donc sa réapparition dans le développement du langage, même si c'est par la très petite porte et qu'il est difficile d'y voir un signe encourageant concernant une intégration plus poussée pour le moment.

Et je n'ai malheureusement pas encore de code PHP à vous présenter concernant ces deux nouveautés, mais j'espère pouvoir le faire rapidement.

Le reste des modifications effectuées sur le trunk sont pour l'essentiel des corrections.

Ainsi, il y a eu un gros travail d'effectuer pour supprimer des messages d'alertes qui survenaient notamment lors de la compilation d'extensions relatives à mysql.

Il est également maintenant possible de compiler le langage avec la dernière version de bison, ce qui n'est pas pour me déplaire.

Et il y a des corrections qui concerne PHP directement, avec par exemple le lot habituel de corrections de bug.

Ainsi, les bugs #52941, #52906, #52879, #52940, #50953, #52971, #50692, #52773, #52774, #52908, #51155, #52981, #51008, #44248, #50345, #52686 et #53021 ont été corrigés.

Outre ces corrections de bugs, il y a également eu quelques optimisations, par exemple au niveau du collecteur d'ordure ramasse-miettes qui devrait être plus fiable ou au niveau du Zend Engine qui devrait être encore (un poil) plus rapide, car des appels inutiles à des fonctions lourdes en terme de performance ont été supprimé.

Le code des fonctions html_entity_decode() et htmlspecialchars_decode() , avec à la clef, et je cite, un dramatic improvements on the performance.

Les nouvelles versions de ces fonctions semblent en effet se révéler 20 à 25 fois plus rapide que les précédentes, et de plus, elles font maintenant plus de choses puisqu'elles sont maintenant capable de gérer les entités telles que ", ', ' et ' et qu'en plus, elles sont prêtes à supporter l'Unicode.

La fonction dns_get_record() a également été modifiée, puisqu'elle supporte maintenant un cinquième paramètre qui permet de récupérer les données brutes renvoyées par un serveur DNS.

Enfin, les fonctions getrandmax() et mt_getrandmax() sont désormais obsolètes et remplacées par les constantes PHP_RAND_MAX et PHP_MT_RAND_MAX.

Et comme je l'ai indiqué en introduction, les discussions sur la liste des contributeurs, internals@, ont également été intéressantes.

Une nouvelle RFC a en effet été proposée.

Elle présente une nouvelle interface nommée \comparable qui a pour but de permettre au développeur de définir une méthode de trie pour ses objets en rendant obligatoire au niveau des classes qui l'implémente la définition de la méthode \comparable::compareTo().

Cette proposition n'a pas été refusée d'emblée, mais elle est encore à l'étude car elle pose un certain nombre de problèmes, notamment sur ce qui doit se passer lorsqu'un objet est comparé à un scalaire, et sur la signification du trie sur des objets.

Par ailleurs, des développeurs du langage y voit également une surcharge des opérateurs de comparaison, et ils y sont plutôt hostiles.

Bref, comme d'habitude, ça discute sévère, dans le plus grand respect et l'amabilité la plus totale évidement, et qui plus est avec des arguments tout ce qu'il y a de pertinents.

Ce débat a de plus généré une discussion parallèle sur la pertinence d'ajouter une fonction par défaut à PHP permettant aux développeurs de faire des comparaisons entre variable.

Cette proposition a reçu un accueil plutôt favorable, même si certain ne sont pas convaincu.

Il y a également eu un autre débat, au sujet des formats de date actuellement supporté par PHP, qui a donné lieu à quelques échanges d'amabilités.

Enfin, j'ai adoré la discussion au sujet de la gestion de la méthode magique __invoke() par le langage et son manque de cohérence, surtout la partie ou il est dit que les traits ont été ajouté au langage pour résoudre ce genre de problème.

Bien évidement, je dit cela sans la moindre ironie...

Cette rétrospective est maintenant terminée, vous pouvez reprendre une activité normale.