PHP 8.2 apportera de nouvelles fonctionnalités et les améliorations de performances,

Annoncée pour la fin de 2022

Le 2022-04-26 08:14:05, par Bruno, Chroniqueur Actualités

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 :

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 :

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 :

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 :

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 :

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 :

1
2
3
4
5
6
7
8
9
function test(
    $foo,
    #[SensitiveParameter] $bar,
    $baz
) {
    throw new Exception('Error');
}
 
test('foo', 'bar', 'baz');

Fatal error: Uncaught Exception: Error in test.php:8
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

Discussion forum

9 commentaires

Pierre Louis Chevalier
Expert éminent sénior

PHP c'est toujours la technologie Web numéro 1 en France quoi qu'on en dise, et même au niveau mondial : PHP conserve la première place en tant que langage de programmation côté serveur sur le Web avec près de 79% d'utilisation .

Après PHP avec un Framework genre Laravel ou Symfony ça reste tout à fait utilisable en entreprise, et c'est ce qui se passe

le 28/04/2022 à 15:19
calande
Nouveau membre du Club

Bonjour, pensez-vous que c'est une bonne idée d'apprendre le PHP à l'heure actuelle ? Je vois la popularité de PHP qui décline peu à peu au fil des années (index TIOBE par ex.) et j'ai peur que d'ici une dizaine d'années, ce langage devienne marginal comme l'est devenu le Perl. Je suis inquiet d'investir beaucoup d'énergie et de me lancer sur des années d'apprentissage pour un langage amené à décliner. Qu'en pensez-vous ?

le 02/09/2022 à 23:38
Séb.
Expert éminent

Perl a toujours été un langage de niche. Je minquieterai pour PHP le jour où d'autres langages/technos permettront de mettre en œuvre du web aussi facilement.
À l'heure actuelle, et à mon sens, son seul réel concurrent à ce niveau est une stack Node, mais JS & cie c'est la jungle et une remise en cause quotidienne.
Et puis, comme pour tout langage, c'est le principe qui compte. Si tu adoptes PHP, 1. ça ne te demandera pas spécifiquement des années d'apprentissage et 2. l'expérience engrangée te permettra de passer facilement sur une autre techno au besoin. Donc oui, apprend PHP, apprend les bonnes pratiques, apprend à bien structurer tes projets (Laravel/Symfony), ne t'enferme pas dans des trucs comme Wordpress, et garde en tête que PHP n'est pas destiné qu'au web (on peut faire du CLI aussi par ex.).

le 03/09/2022 à 5:54
calande
Nouveau membre du Club

Intéressant... Merci Séb. pour avoir partagé ton avis, oui, c'est vrai, ça se tient.

le 03/09/2022 à 7:09
selmanjo
Membre régulier

J'ai bien aimé le " match " qu'on retrouve dans pas mal de langages

le 08/09/2022 à 15:45
Séb.
Expert éminent

PHP ne plait évidemment pas aux consultants qui vendent du Java

le 28/04/2022 à 17:35
polkduran
Membre actif

Mince

le 28/04/2022 à 14:53

Poster une réponse