Tout d'abord, le calendrier a été respecté, et cela malgré l'indisponibilité depuis deux semaines de bugs.php.net, suite à un crash matériel et à l'impossibilité pour les contributeurs en charge de sa maintenance d'y avoir un accès physique pour en extraire les données.
Il était en effet impossible de sortir une version alpha, par définition potentiellement très instable, sans disposer de l'outil ad hoc pour collecter les rapports de bugs, et de gros efforts ont donc été mis en œuvre pour régler ce problème.
La date de sortie a donc été respectée malgré un contexte très défavorable et ce seul fait est donc déjà un événement, car par le passé, des échéances similaires avaient été placées à plusieurs reprises mais n'avaient jamais été respecté, malgré l'absence de problème technique.
Ensuite, il s'agit de la première version significative
au niveau fonctionnel depuis presque deux ans et qui ne soit donc pas une version de maintenance
de la branche 5.3.
Cette version 5.4 apporte en effet un certain nombre de nouveautés, comme par exemple un serveur http intégré destiné à faciliter le développement, le support natif de Dtrace ou bien encore le support des traits au niveau de la programmation orientée objet.
Elle vient également avec ce qu'il est appelé communément au sein de la communauté des contributeurs du syntaxic sugar
, qui rendra l'écriture du code plus confortable pour les développeurs.
De plus, PHP 5.4 représente une rupture significative avec les versions antérieures, car si historiquement chaque nouvelle version majeure ou intermédiaire étaient plus ou moins incompatibles avec les précédentes, 5.4 va beaucoup plus loins que les précédentes à ce niveau.
Certains boulets historiques du langage ont en effet été supprimés, comme par exemple le mécanisme des magic quotes
, celui des register globals
ou bien encore le safe mode
ou les short tags
.
Les développeurs ont d'ailleurs prévus de ne pas s'arrêter là et le nettoyage devrait d'ailleurs se poursuivre dans les prochaines versions.
Cependant, il devrait se faire dans la mesure du possible et majoritairement par l'introduction de nouvelles API, et non par la suppression de fonctionnalités, ceci afin de conserver au maximum la sacro-sainte compatibilité avec les versions antérieures du langage.
Il n'y a donc aucune chance de voir un jour par exemple l'API des fonctions permettant de manipuler les chaînes de caractères uniformisée afin qu'elle soit cohérente en terme de nommage des fonctions et d'ordre des arguments.
Cependant, il est possible qu'il soit ajouté un jour au langage une classe \php\string
qui disposera, elle, d'une interface revue et corrigée, et de plus susceptible de supporter Unicode.
Nous disposerons alors à ce moment d'un langage permettant d'écrire du code propre
tout en permettant l'exécution de code reposant sur d'ancienne version.
En parlant d'Unicode, c'est également l'une des raisons qui font que PHP 5.4 peut être considérée comme une version historique.
En effet, les développeurs de PHP ont décidé pour l'instant de faire l'impasse sur son support, et PHP 5.4 n'apporte donc rien de nouveau à ce niveau, alors que c'était l'objectif principal de PHP 6.
Personne au sein de la communauté ne semble en effet pour le moment capable de dire ce que signifierait supporter Unicode au niveau de PHP, tant au niveau technique que fonctionnel.
Cependant, le sujet revient de manière récurrente sur le tapis sur la liste de diffusion des contributeurs, internals@, et tout espoir n'est donc pas perdu pour qu'un jour, la situation se décante à ce niveau et qu'une solution performante à tout point de vue soit trouvée.
Dans l'intervalle, il faudra faire avec les outils existants, tels que intl
ou mbstring
, la refonte de ce dernier ayant d'ailleurs fait l'objet d'une RFC.
Enfin, il s'agit de la première version du langage dont le processus de release est formalisé et connu.
La RFC relative au processus de release du langage a en effet été entérinée par une large majorité des contributeurs, et elle servira donc de cadre pour PHP 5.4.
En conclusion, le langage est vivant, s'assainit et cela malgré les aléas qu'il a rencontré au cours de son développement ces dernières années.
De plus, son développement se formalise et se structure, via des processus écrits, librement consultables et mis en place à l'issue d'un vote permettant à toutes les personnes impliquées de s'exprimer.
Le langage est donc sur un chemin très différent, à la fois plus ouvert et plus balisé, que celui qu'il suivait avant l'arrêt du développement de PHP 6.
Il ne reste donc plus qu'à lui souhaiter bonne route !
17 réactions
1 De Guile - 29/06/2011, 15:47
Un article vraiment bien écrit ! C'est plaisant à lire autant d'optimisme !
C'est beau le futur
2 De Nami - 29/06/2011, 16:07
Eh bien ! Voici qui fait plaisir... Un avenir se profilerait pour PHP ?
3 De Stopher - 29/06/2011, 20:59
Merci pour cet article ,
ça fait du bien de lire un point de vue positif
Et Merci aux contributeurs du core PHP.
Ch.
4 De Séb - 29/06/2011, 21:10
Très bon billet. Enthousiame partagé !
Petite question, j'utilisais souvent les "short tags" (pour mes templates), c'était pratique et plus élégant que le "<?php".
Vu qu'ils seront supprimés, est-ce que c'est une bonne idée de les remplacer par des "asp tags" ?
5 De Séb - 29/06/2011, 21:19
P.S : Pour ceux qui veulent tester cette version, elle est déjà disponible sous Gentoo ! J'en profite pour faire un peu de publicité pour cette distribution Linux, qui est très flexible pour un PHP aux petits oignons (auto-patching, compilation personnalisée, etc. et le tout très facilement avec le gestionnaire de paquets).
6 De Matthieu - 29/06/2011, 22:18
"une classe \php\string" > Oui ! J'attends ça avec impatience. Par contre la suppression des short tags, est-ce que ce short tag va être supprimé aussi : "<?=" ? Si oui, y'a t'il un remplacement de prévu ? C'est vraiment (vraiment !) dommage de perdre cette notation si pratique dans les vues HTML !!
7 De oxman - 29/06/2011, 23:44
Je ne vois pas de trace du serveur http intégré sur http://fr.php.net/releases/NEWS_5_4...
Ni nul part dans la version windows que j'ai téléchargé.
Tu t'es trompé dans ton message ou c'est moi qui ai pas trouvé l'info ?
8 De mageekguy - 29/06/2011, 23:49
@Séb, @Matthieu: La notation <?= a été rendues indépendante techniquement des par
DieuRasmus lui-même avant la suppression de ces derniers.Elle est donc toujours disponible avec PHP 5.4, et la remplacer par des tags ASP (quelle idée bizarre ;)) aurait été une très mauvaise idée, car je pense que leur avenir est compromis.
9 De mageekguy - 29/06/2011, 23:51
@oxman : Le serveur http a été intégré à la branche 5.4 il y a 9 jours, mais effectivement, le serveur http intégré ne sera présent que dans la Alpha 2.
10 De Séb - 30/06/2011, 09:25
C'est juste que c'est très moche et pas super pour la lisibilité d'ajouter chaque fois "<?php" dans un template. "<?" et "<%" , c'est plus court et élégant. Ceci-dit, je vois pas trop en quoi c'était génant ce "<?", je connais pas 1000 personnes qui parsent des fichiers PHP !
11 De mageekguy - 30/06/2011, 11:10
@Séb : Incompatibilité avec xml/xhtml.
12 De Séb - 30/06/2011, 12:41
Ah merci, j'avais pas compris où se situait exactement le problème avec ce "<?".
Au passage, bonne idée d'utiliser l'espace de noms /php pour recréer une API cohérente.
13 De mageekguy - 30/06/2011, 14:04
@Séb : En ce qui concerne l'espace de nom
\php
, rien n'est encore fait, et il en va de même pour\php\string
, qui n'est qu'un exemple pour expliquer comment PHP va évoluer par rapport à ses API non cohérente.D'ailleurs, la discussion au sujet de l'espace de nom \php a fait brièvement parti de la feuille de route, mais n'y figure plus, sans que j'ai plus d'informations sur le sujet.
14 De artragis - 02/07/2011, 16:10
Bonjour,
je ne suis pas un professionnel, mais je suis le développement de PHP et ton blog est très bien fourni, d'autant plus qu'il est très précis.
Je dois avouer que je suis heureux que les shorts tags soient ôtés et seule la notation <?= retenue car elle reste plus courte et agréable que <?php dans les pages html.
Pour la classe \php\string, si j'ai bien compris ça sera juste un objet qui rassemblera les anciennes méthodes mais elles seront renommée et leurs arguments réordonnés de manière cohérente (camelCase?)? Je me trompe?
Ma grande joie en tant qu'étudiant qui aime le développement web reste la suppressions de register_globals et des magic quotes.
Je ne crache pas non plus sur l'amélioration des performances.
Enfin, en jetant un coup d'oeuil au SVN de PHP j'ai pu remarquer avec étonnement que certaines fonctions de la SPL étaient gravement buggées et parfois pas totalement implémentées (RegexIterator::REPLACE, par exemple). Je trouve cela dommage quand on voit les performances accrues des outils de la SPL.
15 De stealth35 - 03/07/2011, 16:55
@artragis, la doc n'est pas forcement à jour, RegexIterator::REPLACE est arrivé avec la 5.3.4 (j'avoue c’était un peu tard).
16 De artragis - 05/07/2011, 18:44
Non seulement la doc dit que ça n'est pas implémenté (noir sur blanc : pas encore totalement implémenté) mais en plus le SVN dit aussi "implémentation complète de RegexIterator::REPLACE") donc pour la 5.4....
J'ai vu aussi pas mal de corrections pour les objets style FixedArray.
17 De Zéfling - 14/07/2011, 19:53
J'espère qu'il y aura un jour un support cohérent de l'Unicode, j'ai marre de faire des trucs imbitables pour arriver à faire des découpages de chaînes sans prise en compte de la case.
En plus, l'Unicode est trop mal géré par mbstring (notamment les kana et certaines lettres) et pallier ses lacunes par rapport à MySQL rend parfois la chose bien complexe juste pour exécuter un strpos ou une expression régulière.
En tout cas, je plains les Japonais qui se servent de PHP.