PHP 8.2 sera probablement publié à la fin de 2022, mais aucune date n'a encore été fixée. De nouvelles fonctionnalités, les améliorations de performances, les modifications et les dépréciations sont attendues.Les techniquement null et false pourraient être considérés comme des types valides par eux-mêmes. Les exemples courants sont les fonctions intégrées de PHP, où false est utilisé comme type de retour en cas d'erreur. Par exemple, dans file_get_contents :
| Code : | Sélectionner tout |
file_get_contents(/* … */): string|false
Notons que l'utilisation de false dans un type union était déjà possible ; mais en PHP 8.2, il peut être utilisé comme un type autonome :
| Code : | Sélectionner tout |
1 2 3 4 | function alwaysFalse(): false
{
return false;
} |
Selon Brent Roose, de nombreux développeurs, dont lui-même, sont un peu méfiants en regardant la RFC qui traite de True et False. « Elle ne prend pas en charge true en tant que type autonome, et les types ne devraient-ils pas représenter des catégories plutôt que des valeurs individuelles ? », s’interroge-t-il. « Il s'avère qu'il existe un concept appelé type unitaire dans les systèmes de types, qui sont des types qui ne permettent qu'une seule valeur. Mais est-ce vraiment utile, et est-ce que cela encourage la conception de logiciels propres ? Peut-être, peut-être pas. », ajoute-til. Un type null autonome est un peu plus logique : null peut être considéré comme une catégorie en soi et pas seulement comme une valeur dans une catégorie.
Modèle d'objet null
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | class Post
{
public function getAuthor(): ?string { /* … */ }
}
class NullPost extends Post
{
public function getAuthor(): null { /* … */ }
} |
Il est logique que NullPost::getAuthor() puisse dire qu'il ne retournera jamais que null, au lieu de null ou string, ce qui n'était pas possible auparavant.
Brent Roose recommande d’éviter d'utiliser false comme un type autonome pour transmettre un état d'erreur « je pense qu'il y a de meilleures solutions pour résoudre de tels problèmes. »
Dépréciation des propriétés dynamiques
Les propriétés dynamiques sont dépréciées en PHP 8.2, et lèveront une ErrorException en PHP 9.0. Rappelons que les propriétés dynamiques sont des propriétés qui ne sont pas présentes sur un objet, mais qui sont néanmoins définies ou obtenues :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 | class Post
{
public string $title;
}
// …
$post->name = 'Name'; |
Les classes implémentant __get et __set fonctionneront toujours comme prévu :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | class Post
{
private array $properties = [];
public function __set(string $name, mixed $value): void
{
$this->properties[$name] = $value;
}
}
// …
$post->name = 'Name'; |
Pour Brent Roose, le PHP était autrefois un langage très dynamique, mais il s'est éloigné de cet état d'esprit depuis un certain temps déjà. Ce dernier pense que c'est une bonne chose d'adopter des règles plus strictes et de s'appuyer sur l'analyse statique partout où cela est possible, car cela permet aux développeurs d'écrire un meilleur code.
Redact les paramètres dans les traces
Une pratique courante dans toute base de code est d'envoyer les erreurs de production à un service qui en garde la trace et notifie les développeurs lorsque quelque chose ne va pas. Cette pratique implique souvent l'envoi de traces de pile par câble à un service tiers. Il y a cependant des cas où ces traces de pile peuvent inclure des informations sensibles telles que des variables d'environnement, des mots de passe ou des noms d'utilisateur.
PHP 8.2 permet de marquer ces « paramètres sensibles » avec un attribut, de sorte que l'utilisateur n'ait pas à se soucier de leur présence dans les piles de traces lorsque quelque chose ne va pas. Voici un exemple tiré de la RFC :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | function test(
$foo,
#[SensitiveParameter] $bar,
$baz
) {
throw new Exception('Error');
}
test('foo', 'bar', 'baz'); |
Stack trace:
#0 test.php(11): test('foo', Object(SensitiveParameterValue), 'baz')
#1 {main}
thrown in test.php on line 8
Dépréciation partielle supportée par les callables
Un autre changement, bien qu'ayant un impact légèrement plus faible, est que les callablespartiellement supportés sont maintenant dépréciés également. Les callables partiellement supportés sont des callables qui peuvent être appelés en utilisant call_user_func($callable), mais pas en appelant $callable() directement. La liste de ces types de callablesest assez courte, d'ailleurs :
- "self::method"
- "parent::method"
- "static::method"
- ["self", "method"]
- ["parent", "method"]
- ["static", "method"]
- ["Foo", "Bar::method"]
- [new Foo, "Bar::method"]
La raison de ce choix ? Pour certains programmeurs, il s'agit là d'un pas dans la bonne direction vers la possibilité d'utiliser callable pour les propriétés typées. C'est bien expliqué dans la RFC :
« tous ces callables sont dépendants du contexte. La méthode à laquelle self::method fait référence dépend de la classe à partir de laquelle l'appel ou la vérification de callability est effectué. En pratique, cela vaut également pour les deux derniers cas, lorsqu'ils sont utilisés sous la forme [new Foo, "parent::method"].
La réduction de la dépendance contextuelle des callables est l'objectif secondaire de ce RFC. Après cette RFC, la seule dépendance de portée qui reste est la visibilité de la méthode : Foo::bar peut être visible dans une portée, mais pas dans une autre. Si les callables devaient être limités aux méthodes publiques à l'avenir (tandis que les méthodes privées devraient utiliser des callables de première classe ou Closure::fromCallable() pour être rendues indépendantes de la portée), alors le type callable deviendrait bien défini et pourrait être utilisé comme un type de propriété. Cependant, les modifications de la gestion de la visibilité ne sont pas proposées dans le cadre de ce RFC. »
Source : Brent Roose's blog
Et vous ?
Quel commentaires posez vous sur cette analye de Brent Roose, Programmeur PHP ?Voir aussi :
PhpStorm 2021.3 est disponible avec la prise en charge complète de PHP 8.1, une meilleure gestion des génériques PHP, le développement à distance et bien d'autres améliorations JetBrains lance le programme d'accès anticipé (EAP) à PhpStorm 2022.1, la première mise à jour majeure de l'année de son EDI pour le développement Web avec PHP La première version EAP de PhpStorm 2021.3 est disponible : prise en charge complète de PHP 8.1 et bien d'autres améliorations et nouveautés La version 2021.2 de PhpStorm, l'EDI de JetBrains pour le développement Web avec PHP, est disponible : tour d'horizon des nouveautés et améliorations 
