Elle nous apprend en effet que la première release candidate
est prévue pour septembre 2011, et qu'elle devrait être suivie par d'autres toutes les deux semaines jusqu'à ce que la stabilité du langage soit jugée satisfaisante.
D'ici là, nous devrions pouvoir nous mettre sous la dent fin juillet une autre version alpha, suivie par une beta fin août.
Le calendrier est donc clair, mais j'éviterais de trop m'y fier, car par le passé, de tels jalons ont déjà été posés et n'ont jamais été atteints.
La situation d'aujourd'hui est cependant très différente de celle de l'époque, car beaucoup de problèmes ont été résolus depuis, notamment au niveau de la gestion du projet.
La RFC relative au processus de release du langage est en cours de validation, et les premiers votes semblent indiquer un consensus majeur autour de cette question, même si le nombre de votants est relativement faible pour le moment et que des contributeurs historiques ne sont pas encore exprimés.
J'ai donc bon espoir que le calendrier soit finalement respecté, même si je prédis quelques difficultés d'ici la sortie de la version finale, d'autant qu'elle est sous la responsabilité des release managers
Stanislav Malyshev, aka stas, et David Soria Parra, aka dsp, qui sont plus actifs sur internals@ que sur le trunk.
Outre le calendrier, la feuille de route nous apprend également ce qu'il reste à faire au niveau technique et fonctionnel d'ici septembre 2011.
Elle nous apprend notamment que faire passer un maximum de tests unitaires au vert reste une préoccupation forte depuis la remarque de Dieu Rasmus Lerdorf à ce sujet.
La gestion des traits, et plus particulièrement de leur interaction avec l'introspection, est aussi au menu des contributeurs.
Ce point semble d'ailleurs être relativement délicat, car les choses ne semblent pas avoir évoluées depuis ma discussion à ce sujet avec Stephan Maar, l'auteur de l'implémentation des traits dans PHP, lors du rendez-vous AFUP correspondant.
Cela confirme cependant que les traits feront bien partis de la version 5.4, sauf problème majeur.
Du nettoyage est en outre prévu, notamment au niveau des SAPI qui ne sont plus maintenues et qui devraient donc être supprimées.
Il reste de plus quelques patches à intégrer, relatif à la gestion des signaux au niveau du Zend Engine et à la gestion des erreurs, qui devraient être plus explicite avec cette nouvelle version.
Un patch permettant également de faire appel à un attribut ou une méthode de classe aussitôt un appel à l'opérateur new
devrait également être intégré.
Enfin, il faut également que les contributeurs s'assurent que la documentation relative à l'installation de PHP 5.4 est à jour.
La liste des choses à faire au niveau technique est donc encore longue, et la liste fonctionnelle n'est pas en reste, car de nombreux points, souvent très conflictuels au sein de la communauté, doivent encore être évoqués.
Les contributeurs semblent vouloir entre autre réserver un espace de nom au langage, qui pourrait être \php
.
Cependant, pour l'instant, il n'est pas précisé l'usage qu'il pourrait en être fait à l'avenir dans la feuille de route, et je n'ai pas encore pris le temps de rechercher des informations complémentaires.
Ils doivent également discuter de la pertinence de transformer int
, float
et les autres types natifs en mot réservé, dans l'optique de mettre en place un jour le contrôle de type sur les arguments.
L'idée n'est donc pas encore abandonnée, malgré les débats houleux qu'elle a suscité par le passé parmi les développeurs de PHP.
L'erreur E_STRICT
pourrait de plus faire parti de E_ALL
avec PHP 5.4, et il pourrait être possible d'avoir au sein de $_POST
les données brutes reçues par le serveur.
Le support de la notation binaire pour les entiers est également au programme et viendrait, si elle était adoptée, compléter la notation octale et hexadécimale.
Les magic quotes
, l'un des plus gros boulets historiques du langage, pourrait de plus venir s'ajouter à la liste des boulets supprimés, qui contient déjà les directives safe_mode
, register_globals
ainsi qu ses dérivés.
En terme de syntaxe, la possibilité d'utiliser une syntaxe plus courte pour la définition des tableaux devrait être à nouveau discutée, peut être grâce à l'arrivée sur internals@ de Robert Eisele, l'auteur du fork
récent de PHP qui intègre une telle fonctionnalité.
Et si les discussions aboutissent, PHP 5.4 devrait disposer d'un serveur web intégré destiné au développement (et uniquement au développement).
Enfin, les contributeurs veulent également parler de l'utilisation d'une classe native pour la gestion des sessions, et du fait de pouvoir imposer un type callback
pour un argument de fonction ou de méthode.
Le programme pour les mois à venir est donc précis, mais chargé.
7 réactions
1 De Damien - 21/06/2011, 13:26
Toute petite précision, bien que la branche 5.4 alpha 1 ait été créée, la version sort réellement le 28/06, d'après https://wiki.php.net/todo/php54 et les quelques bouts de mail que j'ai vu passé.
2 De MathRobin - 21/06/2011, 14:56
Super point comme d'habitude, merci!
Tu sais que j'ai presque hurlé de joie au boulot quand j'ai lu ça "Ils doivent également discuter de la pertinence de transformer int, float et les autres types natifs en mot réservé, dans l'optique de mettre en place un jour le contrôle de type sur les arguments.". C'est encourageant
3 De joey - 22/06/2011, 00:12
et à propos des performances, y a-t-il des infos à se mettre sous la dent ?
je n'ai trouvé qu'un bench fait par l'auteur de PHPunit qui montre des progrès sensibles (20% plus rapide, 37% de mémoire économisée (!)), mais qui ne dit rien sur les configurations de test (avec ou sans APC, au hasard).
http://pastebin.com/TrmDqPqw
4 De joey - 22/06/2011, 00:16
autant pour moi, le lien de l'article précédent ( http://svn.php.net/viewvc/php/php-s... ) contient les infos qui m'intéressent.
5 De mageekguy - 22/06/2011, 07:32
@joey : Mes tests avec une configuration du trunk, donc sans extension non native, et du code du monde réel (dont celui d'atoum), avait confirmé ceux avancé par Sébastien Bergman, à savoir approximativement 30% de gain en moyenne.
Je pense que ces mesures sont toujours d'actualité, et effectivement, tu une partie des modifications et des optimisations effectuées dans le fichier NEWS, notamment celle qui ont un impact sur l'API interne de PHP.
Pour le reste, il faut lire les patches, et je te souhaite donc bon courage si tu veux les analyser ;).
6 De joey - 22/06/2011, 10:50
il faudra que j'attende des benchs avec APC alors car de 5.2 à 5.3 on avait aussi un gain important en interprété mais quasi nul une fois APC activé (et qui utilise PHP sans APC, finalement ?).
reste l'économie de mémoire : dans ton ancien article il y avait aussi un bench avec PHPUnit et même s'il a changé, elle est passée de 26% à 37% en un an.
7 De mageekguy - 22/06/2011, 11:21
@joey : Ce que tu me dis me semble cohérent, car si j'ai bien compris, beaucoup des optimisations faites à ce niveau utilise des techniques issues d'APC ou l'expérience acquise avec APC.
Je ne suis donc pas surpris que son activation ne change pas grand chose dans certain cas, en fonction de la version de PHP utilisée et de la nature du code exécuté.