Il semble cependant raisonnable de tabler sur notamment un support des traits, le support de DTrace, la possibilité d'écrire maFonction()[0]
et d'utiliser $this
avec les fermetures lexicales.
De plus, la console de PHP ne devrait plus se terminer lorsqu'une erreur fatale est générée et autoconf 2.59+ est maintenant supporté.
Des boulets historiques de PHP vont de plus disparaitre avec cette version tels que les directives safe_mode
, register_globals
et register_long_array
ainsi que le passage explicite d'argument par référence.
Par ailleurs, un gros travail d'optimisation a été réalisé, et cette version de PHP devrait être significativement plus rapide que les précédentes, et moins gourmande en mémoire.
Enfin, le support de Windows a été grandement amélioré, et il devrait être à l'avenir plus simple de compiler le langage sur cette plate-forme.
Et cette liste est loin d'être exhaustive, puisqu'au moment de la rédaction de ce billet, le fichier décrivant les modifications subit par le langage fait plus de 6000 lignes, réparties entre les ajouts de fonctionnalités, les corrections de bugs, des améliorations d'extensions et les optimisations apportées au Zend Engine.
Il faudra cependant attendre encore quelques temps avant de pouvoir profiter de tout cela en production, puisque la version finale est pour l'instant prévu pour le milieu du quatrième trimestre de cette année.
Je suis bien évidement très heureux que cette version pointe enfin officiellement le bout de son nez.
Cependant, je dois avouer que cette naissance ne se passe pas si bien que je l'aurais voulu.
En effet, la communauté PHP semble toujours aussi divisée, entre ceux qui cherchent à faire évoluer le langage, et ceux qui au contraire veulent le contraindre à la stabilité, pour ne pas dire l'immobilisme pour les cas les plus extrêmes.
Pour preuve, la RFC relative au processus de release du langage n'est toujours pas validée, malgré les efforts de ses auteurs, et vu d'avion, la communauté semble être comme un paquebot sans gouvernail dirigé par un équipage de mutins qui aurait mis le capitaine à fond de cales.
La mort de PHP 6 n'a donc pas à ce jour réussi à créer une union sacré au sein des contributeurs, ou à tout le moins à apporter de la rigueur et un minimum de consensus dans le développement de PHP, malgré les efforts déployés pour cela par toute une partie des contributeurs et qui ont notamment lutté milité pour la mise en place du wiki, des RFC, et pour que les utilisateurs et les développeurs non historiques
du langage aient la possibilité d'influencer sur son développement.
11 réactions
1 De Joris - 20/06/2011, 00:44
Excellente chose tout cela !
Cependant, on attend toujours l'arrivée de PHP 5.3 sur les plate-formes mutualisées alors j'ose même pas espérer quand sera le tour de PHP 5.4...
2 De Da Scritch - 20/06/2011, 08:58
Je ne hais plus les Lundis.
3 De Fred - 20/06/2011, 10:24
... a ce rythme la en 2050 on sera a php 5.9 et ASP.NET en ASP.NET 30 lol Depuis 2004 qu'on a PHP5 a force de faire des versions mineures on aurait pu avoir une version majeure ne serait ce que pour ne pas avoir l'impression que le langage n'évolue pas et pour que quand on recrute du monde on puisse faire la différence entre les compétences des développeurs parce qu'entre ceux qui ont fait un peu de php 5.0 et ceux qui suivent assidument les versions ... mais c vrai que j'ai un peu de mal a comprendre au niveau des différents acteurs qui c qui commande vraiment ! (p't'etre un sujet d'article un jour de savoir qui fait quoi dans le monde du php)
P.S. : pbm de lien dans "assez conséquente" (hhttp => http)
4 De mageekguy - 20/06/2011, 10:37
@Fred : Pour le lien, ça avait déjà été signalé et donc corrigé.
Et faire un billet expliquant le fonctionnement de la communauté n'est pas évident, car tout reste à faire, ou est en train de se faire, plus ou moins rapidement, en fonction des résistances rencontrées, qui peuvent être virulentes.
PHP n'a pas de leader, comme Python, par exemple, et au sein de la communauté, la résistance est changement est très forte de la part d'une partie des développeurs historiques, ce qui conduit à des solutions ubuesques comme PHP 6 ou celle d'aujourd'hui, avec le lancement d'un processus de release (car c'est ce que représente cette version alpha) alors que le processus de release n'est pas formalisé.
5 De Laurentj - 20/06/2011, 10:55
Je ne vois pas les raisons qui pousseraient à sortir en 6.0 plutôt que 5.4. Je trouve qu'il y a moins d'améliorations "disruptive" dans cette 5.4 que dans la 5.3. J'ai plus l'impression que la 5.4 est une version d'amélioration de la 5.3 qu'autre chose.
6 De Fred - 20/06/2011, 11:06
... d'accord en fait au début je ne me posait jamais la question de savoir qui c qui fait quoi mais au fur et a mesure que je lis ton blog je me dis : mais c pas possible y a personne aux commandes du navire ! J'ai l'impression que parfois ca ressemble a une cour de récréation ou certains developpeurs se chamaillent avec de temps en temps des piliers du langage qui interviennent pour régler les conflits ... ce qui fait limite peur !
7 De Bob l'éponge - 20/06/2011, 14:20
Peut tu expliquer "passage explicite d'argument par référence" ?
Merci
8 De mageekguy - 20/06/2011, 14:52
@Bob l'éponge :
maFonction(& $a)
, qui génère un avertissement actuellement, ne sera plus accepté.9 De metagoto - 20/06/2011, 19:30
@Bob l'éponge: précision par rapport à ce qu'a dit mageekguy: c'est supprimé lors de l'appel (allow_call_time_pass_reference) mais c'est toujours valable pour la déclaration des fonctions.
10 De Sébastien - 21/06/2011, 07:33
Signalons au passage les récentes interventions de Robert Eisele, auteur d'un récent fork de PHP et qui semble vouloir s'impliquer dans le développement de PHP. Bonne nouvelle et espérons que PHP aille de l'avant !
http://www.xarg.org/2011/06/php-hac...
Malheureusement, beaucoup de patchs ont déjà été proposés par le passé, souvent sans jamais être intégrés ou même commentés.
Je pense par exemple à __getStatic(), que j'utilise depuis maintenant 2 ans en production (avec une version patchée-maison de PHP), mais qui n'est toujours pas disponible officiellement.
J'ai même essayé de relancer le sujet dernièrement : aucune réponse, alors que la patch est fonctionnel et que ces fonctions magiques sont prévues dans la RFC (__setStatic() est déjà implémentée, allez savoir pourquoi ses petits soeurs n'ont pas été ajoutées en même temps).
http://sitten-polizei.de/php/getsta...
11 De mageekguy - 21/06/2011, 09:32
@Sébastien : Il ne faut pas rêver : Robert ne fera pas bouger les choses, et encore moins tout seul, d'autant que ses patchs posent pour le moment plus de questions qu'autres choses.
Et historiquement, les contributeurs ne sont pas rapides pour trouver des réponses.
Quand à ton patch, il n'a pas été refusé à ma connaissance, il est juste en attente de review par un contributeur et comme le bug tracker est down, ça va certainement prendre un peu de temps.
Il faut être patient.
Et pour information, Robert dit lui même que son fork n'en est pas un.