La nouveauté principale de cette version est sans conteste le support de la syntaxe courte pour la définition des tableaux, suite au vote d'il y a maintenant quelques semaines.
PHP permettra donc dorénavant de créer des tableaux à l'aide de l'une ou l'autre de ces deux notations :
<?php $a = [1, 2, 3]; $b = ['orange' => 'orange', 'pomme' => 'apple', 'citron' => 'lemon']; ?>
Toujours conformément au vote des contributeurs et de la communauté, cette version alpha 3 permet la définition de nombres entiers en notation binaire.
En plus de la notation octale et héxadécimale, les développeurs pourront donc initialiser avec la notation binaire :
<?php $year2010 = 0x7da; // hexadécimale $year2010 = 03732; // octal $year2010 = 0b11111011010; // binaire ?>
La dernière nouveauté significative est une chose que j'attendais depuis très longtemps.
En effet, si PHP est un langage relativement dynamique, puisqu'il est possible de créer un objet à partir d'une variable, via la syntaxe new $class()
, et d'appeler une fonction ou une méthode, voir une propriété d'une manière similaire, via ${expression}()
ou $object->{expression}()
, jusqu'à maintenant, il n'était pas possible de la faire avec une méthode statique.
Cependant, grâce au travail de Pierrick Charon, PHP 5.4 alpha 3 permet d'appeler une méthode statique via une variable, grâce à la syntaxe uneClasse::{expression}()
.
Le mode FPM de PHP a également été un peu amélioré, via l'ajout de la directive de configuration process.max
qui permet de définir le nombre maximum de processus qui peuvent être lancés simultanément.
Pour ce mode, il est également maintenant possible de définir plusieurs fois une même directive de configuration, la valeur finalement retenue étant la dernière définie.
De plus, il n'y a pas eu que des ajouts de fonctionnalités puisqu'il y a également eu des suppressions, et non des moindres.
Décriées depuis des années et reconnues comme étant l'un des plus gros boulets historiques du langage, les magic quotes
appartiennent en effet dorénavant au passé, puisqu'elles ne sont plus supportées par PHP 5.4.
Pour finir, le comportement du langage a également été modifié, puisque le niveau d'erreur E_ALL
contient maintenant par défaut le niveau E_STRICT
.
Les développeurs n'auront donc plus à l'avenir besoin d'activer spécifiquement le niveau d'erreur E_STRICT
dans leur fichier php.ini
, puisque pour en bénéficier il leur suffira d'utiliser E_ALL
.
Ce n'est pas la seule modification dans le comportement du langage, car j'ai découvert une régression qui n'est malheureusement pas actuellement documentée, même si j'ai fais le rapport de bug correspondant.
PHP 5.4 oblige en effet depuis sa version alpha 1 que le constructeur de la classe parente soit appelé dans une classe dérivée d'une des classes de la SPL permettant la manipulation du système de fichier, comme par exemple \DirectoryIterator
, afin de ne pas permettre au développeur de créer des objets dans un état inconsistant.
Si cette nouvelle obligation n'est pas respectée, le langage génèrera une exception, ce qui peut s'avérer un réel problème si du code en production a été écrit de la manière inadéquate.
Cette version alpha 3 est donc significative et n'est pas juste une version corrective, même si elle contient également son lot de corrections de bugs, notamment au niveau de la SPL.
Je vous invite donc à la télécharger dès qu'elle sera disponible afin qu'elle soit testée le plus complètement possible, même si en l'état elle n'est clairement pas adapté à un environnement de production.
Elle vous permettra de patienter jusqu'à la version béta 1, qui devrait être disponible à compter du 25 août 2011, si le calendrier prévu est respecté, ce dont je doute assez peu vu la très forte motivation des contributeurs actuellement.
Et pour la même raison, je pense qu'à cette même date, la liste des choses restant à faire avant la sortie de la version finale de PHP 5.4 devrait être vidée.
[EDIT] Au jour dit, David Soria Parra et Stanislav Malyshev ont rendu disponible la version alpha 3 de PHP 5.4.
14 réactions
1 De Renaud - 04/08/2011, 08:31
Ah ben c'est donc ça que j'ai comme erreur quand je lance n'importe quelle commande symfony 2.
Les commentaires de ton rapports de bug font penser qu'ils n'ont pas envie de corriger, non ?
2 De mageekguy - 04/08/2011, 08:46
@Renaud : Tu penses bien. J'ai pas mal discuté sur IRC avec l'auteur de la modification, et j'ai même porté le débat sur internals@, mais pour l'instant, je n'ai pas réussi à me faire entendre, malheureusement.
Du coup, je suis preneur de toutes informations relatives à ce
dans le cadre de SF2.Et après avoir constaté par moi-même le problème, j'ai mis à jour le rapport de bug en conséquence.
3 De Ivan Enderlin - 04/08/2011, 09:00
Hey :-),
À noter que le dépôt Mercurial existe aussi (http://hg.php.net/), tu ne le soulignes pas assez ;-).
Pour ton bug, la discussion s'est terminée sur le fait qu'on pouvait capturer cette exception dans le constructeur et que le problème était résolu. Non ? J'étais là lors du débat mais il a duré plusieurs heures et quelques choses a pu m'échapper. Tout du moins, tu devrais peut-être relancer sur internals histoire de clarifier les choses car ton sujet n'a pas été repris.
4 De mageekguy - 04/08/2011, 09:04
@Ivan Enderlin : Qu'on est trouvé ou non une solution (je n'ai pas encore testé) n'est pas vraiment la question.
Le problème est qu'il s'agit d'une cassure de compatibilité non documentée qui semble avoir un impact beaucoup plus important que prévu.
J'ai déjà pris les contacts nécessaire sur IRC pour relancer la discussion.
5 De jubianchi - 04/08/2011, 09:29
Bonjour à tous!
Encore une fois, merci @mageekguy pour ce billet très intéressant!
Concernant le "bug" du constructeur cité dans ce billet, ce comportement pose effectivement quelques problèmes de compatibilité (qui ne sont pas documentés) mais (arrêtez moi si je me trompe) l'appel implicite à un constructeur parent ou le non-appel au constructeur parent est une erreur de code : dans la logique c'est à l'auteur de la classe fille de géré cet appel explicitement car sinon, l'initialisation n'est pas complètement faite (le code du constructeur parent n'est pas exécuté).
Je pense donc qu'il y a des erreurs de code dans certains framework ou autres scripts qui devraient être corrigées par leurs auteurs mais l'équipe de dév de PHP aurait également du documenter cette cassure de compatibilité.
6 De mageekguy - 04/08/2011, 10:20
@jubianchi : Ce n'est pas forcément une erreur de programmation.
Dans le cadre de tests unitaires, tu peux vouloir mocker une classe afin de court-circuiter son constructeur, parce que, par exemple, il se connecte à une base de données, ou demande, comme celui de \DirectoryIterator, un chemin d'accès à un répertoire existant sur le système de fichiers, et tu peux vouloir rendre tes tests indépendant de cette base ou du système de fichier.
De plus, tu peux également vouloir déporter dans une autre méthode l'initialisation de l'objet, pour une raison ou une autre.
Appeler le constructeur parent est plus une bonne pratique générale qu'une règle absolue.
7 De Jubianchi - 05/08/2011, 13:33
@mageekguy : je suis complètement d'accord avec cette remarque : en PHP ce n'est pas une règle absolue mais pour moi cette possibilité reste une facilité de programmation.
Si nous étions dans un langage ou le constructeur de la classe racine gère, par exemple, l'allocation des ressources système, il serait dangereux de ne pas appeler explicitement le constructeur parent, de le courcircuiter ou de déporter l'appel dans une autre méthode.
8 De mageekguy - 05/08/2011, 16:30
@Jubianchi : Sauf que tu n'es pas censé savoir ce que fait le constructeur parent techniquement parlant.
C'est donc à la classe mère de gérer correctement le cas ou elle n'est pas instanciée correctement, et elle n'a pas à forcer le développeur à l'utiliser d'une quelconque manière.
9 De Jubianchi - 05/08/2011, 20:09
@mageekguy : je ne veux pas lancé un débat sans fin ou vexer qui que ce soit mais (a mon avis) :
- c'est justement parce que je ne sais pas ce que fait le constructeur que je l'appelle.
- combien de classe sont écrites de manière à vérifier à chaque utilisation que leur initialisation et complètement faite ?
- si une classe mère me force à appeler son custructeur lors de l'instanciation d'une de ses filles, c'est que celle-ci est mal écrite/mal conçue ?
Personnelement je pense que l'appel explicite est plus "propre", plus lisible mais je me trompe peut être d'où mes questions...
10 De Renaud - 08/08/2011, 20:39
Toujours pas réparé
$ php -v
PHP 5.4.0beta1-dev (cli) (built: Aug 8 2011 18:08:55)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies
php ./app/console
[LogicException]
In the constructor of Symfony\Component\Finder\SplFileInfo, parent::__construct() must be called and its exceptions cannot be cleared
11 De mageekguy - 09/08/2011, 10:20
@Renaud : Pour le savoir, il suffit d'aller voir le ticket de bug...
Et je ne suis de toute façon pas du tout certain que le comportement précédent soit un jour rétablie.
Il faudra je pense mettre le code à jour.
12 De Renaud - 09/08/2011, 10:28
Au lieu de parler, j'ai agi: https://github.com/symfony/symfony/...
13 De mageekguy - 09/08/2011, 12:08
@Renaud : J'avais déjà fait remonter l'info vers @hhamon et @fabpot via twitter, mais l'initiative est bonne.
14 De artragis - 30/10/2011, 09:32
Salut, c'est tout nouveau, tout neuf, le bug que tu avais signalé (sous le numéro 55300) vient d'être corrigé par cataphract