Je vais d'ailleurs commencer par ce dernier, car même si le nombre de modifications est important, ces dernières sont beaucoup moins passionnantes que la discussion au sujet des annotations qui a eu lieu sur la liste de diffusion.
Le support des liens symboliques pour la version pour Windows de PHP, amorcé durant la période précédente, continue a être implémenté par Pierre Joye, avec notamment l'ajout de la gestion des liens symboliques au niveau de la directive open_basedir.
Le travail qu'il a réalisé sur ce point précis représente d'ailleurs quasiment la moitié des modifications effectuées sur le trunk, ce qui est loin d'être négligeable.
Un autre gros travai a été effectuée par Dmitry Stogov, sur la gestion de la mémoire par le langage, qui est donc (encore une fois) moins gourmand à ce niveau, même si le gain dépend étroitement du contexte d'utilisation.
J'ai par exemple constaté, notamment lors de la mise en œuvre de la version du trunk en conjonction avec Atoum, mon framework de tests unitaires, une diminution très significative de la consommation de mémoire, de plus de 40% par rapport à PHP 5.3.3.
De plus, les performances de la fonction unserialize() ont de plus été améliorées et les bugs #52802,
#51804,
#49215,
#52826,
#52772,
#48831,
#52827,
#52843,
#52849,
#49366 et
#44331 ont été corrigés.
Le reste des modifications correspond à des optimisations diverses au niveau du Zend Engine, et à du nettoyage du code, avec la suppression de fonctions ou de variables non utilisées ou bien encore de macros C qui sont devenues inutiles et la correction d'erreurs à la compilation.
La description des modifications effectuées sur le trunk de PHP étant maintenant complète, je vais maintenant parler des discussions qui ont eu sur internals@, la liste de diffusion des contributeurs au langage.
Je vais commencer par vous parler de celle relative à l'implémentation des annotations dans le langage, car c'est, et de loin, celle qui a monopoliser le plus la liste.
Pour rappel, tout a commencé le 25 août 2010 lorsque Guilherme Blanco et Pierrick Charron ont proposé une implémentation technique de la RFC relative au support des annotations par PHP, dont ils sont également les auteurs.
Depuis, le débat fait rage, entre ceux qui ne voient aucun intérêt aux annotations et/ou ne veulent pas compliquer le langage, ceux qui y voient un intérêt mais qui, au choix et non exclusivement, n'aiment pas la syntaxe proposée, n'aiment pas l'implémentation proposée, ou ignorent ce que sont les annotations, et ceux qui sont pour les annotations telles qu'elles sont proposées par les deux auteurs de la RFC.
Après des centaines de messages enflammés contenant des arguments plus ou moins recevables, un vote a finalement eu lieu, mais son résultat ne semble pas en faveur de l'implémentation proposée.
Ce résultat est cependant à prendre avec des pincettes.
En effet, le dépouillement a été effectué par mes soins, la communauté des contributeurs ne disposant d'aucun outil efficace pour ce genre de procédure, et j'ai très bien pu louper un vote, voir plusieurs, puisque chaque participant vote en envoyant un message sur la liste de diffusion avec une note pouvant être -1, 0 ou 1, en fonction du fait qu'il est contre, indifférent ou pour l'ajout de la fonctionnalité proposée.
Lors de mon dépouillement, il y avait donc 12 votants, dont 7 négatifs et 5 positifs, ce qui est à mon sens assez peu représentatif.
Pour autant, le débat est loin d'être clos et s'est encore compliquée, puisque deux débats transverses ont émergé.
L'un a pour but d'essayer de formaliser correctement le processus de soumission d'une nouvelle fonctionnalité, mais bizarrement, il n'est pas très actif.
L'autre, beaucoup plus actif, vise à supporter les annotations via le format docblock, même si son auteur s'en défend.
En effet, un support très partiel de ce format est déjà disponible dans PHP via la réflection.
Il semble en effet que ce soit le meilleur compromis actuellement, et en conséquence, la RFC relative à l'interprétation des commentaires au format docblock est au premier plan des discussions.
Bref, tout comme dans le cas du débat sur le contrôle du type des arguments, nous sommes loin d'en voir le bout, et il est difficile de dire si cette fonctionnalité sera un jour intégrée dans le langage et la forme que prendra cette intégration en l'état actuel des choses.
Cette rétrospective est maintenant terminée, vous pouvez reprendre une activité normale.
6 réactions
1 De jubianchi - 20/09/2010, 20:11
Bonjour,
Je viens de découvrir récemment cette série d'articles "Mort de PHP6 +X jours" et je trouve ce concept très sympa pour ceux qui ne suivent pas assidûment le développement de PHP.
J'ai découvert par hasard il y a un petit moment que la reflection de PHP permettait d'interpréter les DocBlock et j'ai tout de suite vu les possibilité que cela apportait...
J'ai fais quelques tests d'implémentations de petites fonctionnalités qui me simplifieraient la vie avec ces DocBlock et j'ai finalement aperçu la RFC sur les annotations.
Habitué au développement C#, j'ai tout de suite vu que celles-ci pouvaient nous apporter beaucoup de chose et j'ai donc écrit une implémentation des annotations en PHP : http://github.com/jubianchi/PHPAnno...
C'est donc avec cette implémentation simple qui permet d'utiliser les "annotations" en PHP, que j'ai décidé de modifier un de mes projets pour illustrer l'utilité de cette technique : http://github.com/jubianchi/PHPOver...
Cette petite classe permet de gérer facilement les surcharges de méthodes/fonctions grâce aux annotations. Je n'ai pas encore eu le temps de mettre à jour le README, vous ne pourrez donc l'utiliser qu'à titre indicatif car la syntaxe n'est plus la même avec les annotations.
Pour finir, je pense personnellement que les annotations sont une bonnes choses pour PHP car elle vont nous permettre de faire beaucoup de choses plus facilement : les exemples de la RFS sont assez parlant je pense (mapper une classe à une entité dans le cas d'un ORM, gérer les surcharges dans mon cas :D, définir plus précisément l'accés aux propriétés d'une classe (getter/setter), ...)
2 De Ben - 21/09/2010, 08:48
Je ne connaissais pas la class Reflection et je la trouve plus élégante que l'implémentation proposée.
Je ne suis pas un habitué des annotations, même si je les ai utilisé en java, et je trouve l'argument de base de la RFC, qui ai en gros les autres le fond faisont le aussi assez douteux. Qu'elles soient utile dans le cas d'un ORM, pourquoi pas. Mais on peut aussi très bien faire sans. Si mes souvenir sont bon avec RoR on parle de "convention plutôt que de configuration".
Ce qui m'embête le plus avec les annotations tel que proposé, c'est qu'elle rende le code illisible et moche alors qu'il devrait pouvoir être lu sans avoir besoin d'avoir à faire tout une gymnastique d'esprit (Mais bon en même temps je suis pour la suppression des commentaires alors je suis mauvais juge).
3 De mageekguy - 21/09/2010, 10:04
@Ben : Pour info, la reflection est disponible depuis PHP 5, soit... 2005.
De plus, l'implémentation proposée repose sur la reflection et c'est d'ailleurs là l'un des points qui posent problème.
4 De Ben - 21/09/2010, 10:41
@mageekguy certes mais je ne prétends par connaitre l'ensemble des class et fonctions php, même si j'essaye de rattraper mon retard.
J'avais mal compris ton propos, je pensais que l'utilisation de la réflexion était juste une alternative à la première implémentation ?
5 De mageekguy - 21/09/2010, 10:44
@Ben : Les deux solutions passent par la mise en œuvre de la reflection, mais de deux manières différentes.
6 De jubianchi - 21/09/2010, 17:38
@Ben : je pense au contraire que les annotations rendent le code plus lisible : est-ce plus facile de lire une annotation qui nous indiquerait directement qu'elle table correspond à telle classe ou bien parcourir le code de la classe afin d'y trouver l'indication ?
C'est sur, les annotations ajoutent encore une "structure" supplémentaire au langage mais je trouve qu'elle permettent d'exposer plus clairement certaines informations qui peuvent parfois être cachées au milieu de dizaine de lignes de code.
En écrivant ces lignes, j'imagine un autre exemple d'utilisation : nous connaissons tous les méthodes magiques __set() et __get(), grâce aux annotations nous pourrions plus facilement spécifier qu'elle propriété est accessible ou pas, et comment, grâce à ces méthodes.
Elle nous permettraient également de mettre en place des contrôle de type sur les valeurs plus facilement.