PHP 8.2 : nouvelles fonctionnalités (avec RFC) et changements

Depuis PHP 8, le langage évolue extrêmement vite. Pour rappel, PHP 8.0 est sorti le 26 novembre 2020 et PHP 8.1 le 25 novembre 2021. Chacune de ces mises à jour apporte son lot de nouvelles fonctionnalités, changements, améliorations au niveau des performances, ainsi qu’une sécurité accrue.

PHP 8.2, qui en fera de même que ses prédécesseurs, sa date de sortie est prévue pour le 24 novembre 2022 (voir “PHP 8.2 Preparation Tasks”).

À l’issu de cet article fort en contenu, vous saurez tout à propos des nouvelles fonctionnalités et changements de PHP 8.2 et vous serez aptes à anticiper des mises à jour éventuels des sites web dont vous avez la charge.

Qu’est-ce qu’un RFC ?

Avant toute chose, je dois vous prévenir que vous allez souvent voir l’acronyme “RFC” dans cet article. RFC veut dire “Request for Comments”. Lorsqu’un contributeur souhaite changer PHP de quelque manière que ce soit, le RFC est discuté puis votée.
C’est une façon démocratique de diriger ce navire gigantesque qu’est PHP, qui a une part de marché de presque 80% en 2022.

Maintenant, découvrons enfin ce qu’il y a de neuf dans PHP 8.2 !

Dépréciation des callables partiellement supportés (RFC)

Avez-vous déjà utilisé la fonction call_user_func() avec l’une des syntaxes ci-dessous ?

"self::method"
"parent::method"
"static::method"
["self", "method"]
["parent", "method"]
["static", "method"]
["Foo", "Bar::method"]
[new Foo, "Bar::method"]

Eh bien sachez qu’elles seront dépréciées dans PHP 8.2, puis supprimées dans PHP 9.0.

Plus d’informations sur le site officiel : PHP RFC: Deprecate partially supported callables

Dépréciation des propriétés dynamiques (RFC)

Les propriétés dynamiques dans PHP ont toujours été source d’erreurs involontaires dont j’ai moi-même été victime. Plutôt que d’autoriser la création d’une propriété dynamique (lors de l’exécution du code), le but est que dans PHP 9.0, une erreur soit déclenchée comme dans la plupart des autres langages de programmation. En attendant, PHP 8.2 provoquera un simple avertissement. (Attention, stdClass conserve la possibilité de créer des propriétés dynamiques.)

class Foo {}
 
$foo = new Foo;
// Deprecated: Creation of dynamic property Foo::$bar is deprecated
$foo->bar = 'baz';

Ceci étant dit, il y a toujours des gens ayant des contraintes bien spécifiques qui les empêchent d’adopter les dernières nouveautés et changements. Pour ceux-là, il y a la possibilité d’utiliser un attribut autorisant la création de propriétés dynamiques.

#[AllowDynamicProperties]
class Foo {}
 
$foo = new Foo;
$foo->bar = 'baz';

Plus d’informations sur le site officiel : PHP RFC: Deprecate dynamic properties

Changement de casse indépendant du langage système (RFC)

strtolower() et strtoupper() ainsi que d’autres ne sont désormais plus sensibles au langage de votre système. Cela permet d’éviter, si vous avez par exemple un langage assez exotique sur votre système, d’obtenir des caractères totalement inappropriés au langage que vous avez défini avec setlocale().

Utilisez plutôt mb_strtolower(), mb_strtoupper() et compagnie.

Plus d’informations sur le site officiel : PHP RFC: Locale-independent case conversion

Censure explicite de paramètres dans le backtrace (RFC)

Tout projet sérieux devrait répondre (entre autres) à ces deux critères :

• Masquer les erreurs en production afin de garder tout détail sensible confidentiel ;
• Utiliser un gestionnaire d’erreurs. (Larabiz par exemple utilise Sentry.)

La fonction première d’un gestionnaire d’erreur est de récupérer automatiquement toutes les exceptions générées par votre site. De cette manière, lorsque vos utilisateurs se heurtent à un problème, vous êtes immédiatement prévenus sans que ce dernier n’ait à vous contacter.
Parfois cependant, les exceptions peuvent contenir des valeurs que vous préfèreriez garder pour vous. Heureusement, un nouvel attribut dans PHP 8.2 permet de les masquer à l’affichage.

function send_message_to(
    $recipient,
    $from,
    #[\SensitiveParameter] $subject,
    #[\SensitiveParameter] $message,
) {
    throw new Exception;
}
 
// Fatal error: Uncaught Exception in foo.php:9
// Stack trace:
// #0 foo.php: send_message_to(
//                 'Terroristes',
//                 'Montgomery Burns',
//                 Object(SensitiveParameterValue),
//                 Object(SensitiveParameterValue)
//             )
send_message_to(
    recipient: 'Terroristes',
    from: 'Montgomery Burns',
    subject: "Vente d'uranium",
    message: 'Lorem ipsum sit amet…'
);

Voilà, les secrets de ce cher Monty Burns sont désormais bien gardés en cas de pépin technique.

Plus d’informations sur le site officiel : PHP RFC: Redacting parameters in back traces

null, true et false deviennent des types à part entière (RFC)

La sécurité des types en PHP est un sujet important depuis quelques années. Si cette particularité du langage est correctement utilisée, cela peut conduire à du code plus strict, mais plus fiable et sécurisé. (Attention, un code strictement typé ne fera jamais autant que des tests automatisés pour la fiabilité de vos projets.)

Avec PHP 8.2, nous pouvons désormais utiliser null, true et false comme types à part entière.
Pour l’exemple, prenons les cas de true et false. Lorsque vous déclarez le type de retour d’une fonction avec bool dans votre code, vous pouvez aussi bien retourner true, false, 0 ou 1. Avec PHP 8.2, vous pourrez être plus strict encore :

function foo() : true|false
{
    // Fatal error: Type contains both true and false,
    // bool should be used instead
    return 0;
}
 
foo();

Plus d’informations sur le site officiel : PHP RFC: Allow null and false as stand-alone types

Note : en réalité, false est utilisable en tant que type dans PHP 8.1, mais seulement lorsqu’il se trouve dans une union de types.

Dépréciation d’utf8_encode() et utf8_decode() (RFC)

Étant donné que je ne comprends pas encore très bien quelle alternative nous pourrions utiliser, je réserve pour plus tard l’explication de ce RFC.

Plus d’informations sur le site officiel : PHP RFC: Deprecate and Remove utf8_encode and utf8_decode

Dépréciation de l’interprétation des variables avec ${} (RFC)

Personnellement, je n’étais pas au courant de l’existence de cette manière d’interpréter des variables dans une chaîne de caractères. Et ce n’est peut-être pas pour rien au final.

À partir de PHP 8.2, ce code déclenchera un avertissement :

$name = 'Bart';
 
echo "Hello, ${name}!";
 
// Deprecated: Using ${var} in strings is deprecated, use {$var} instead

Utilisez plutôt les guillemets doubles :

$name = 'Bart';
 
echo "Hello, $name!";

Ou la syntaxe heredoc :

$name = 'Bart';
 
echo <<<TEXT
Hello, $name!
TEXT;

Plus d’informations sur le site officiel : PHP RFC: Deprecate ${} string interpolation

Les classes en lecture seule (RFC)

Y a-t-il des fans des DTO (Data Transfer Objects) ici ? Parfait. Saviez-vous qu’avec PHP 8.2, votre code deviendra encore plus concis grâce aux classes en lecture seule ? Prenons un exemple simple :

class Pokemon
{
    public readonly string $name;
 
    public readonly int $size;
 
    public readonly Type $firstType;
 
    public readonly ?Type $secondType = null;
}

Il sera enfin possible de verrouiller toute la classe aux modifications après instanciation de votre objet :

readonly class Pokemon
{
    public string $name;
 
    public int $size;
 
    public Type $firstType;
 
    public ?Type $secondType = null;
}

Plus d’informations sur le site officiel : PHP RFC: Readonly classes

Déclarations de types conditionnels (Disjunctive Normal Form Types) (RFC)

Le RFC dont nous allons parler s’appelle “Disjunctive Normal Form Types”. Je ne sais pas pour vous, mais pour moi, c’est imbuvable et il m’est impossible de comprendre de quoi nous parlons simplement en lisant le titre. Grossièrement résumé, PHP 8.2 autorisera plus de flexibilité sur la déclaration des types.

function foo((A&B)|(C&D&E)|Bar|null $baz) {
    …
}

Dans ce code, nous demandons un argument $baz implémentant les interfaces A et B ou C, D et E ou un objet de type Bar ou null. Imaginez maintenant voir ce code pour la première fois :

function foo((PremiereInterface&SecondeInterface)|(TroisiemeInterface&QuatriemeInterface&CinquiemeInterface)|UneClasseQuelconque|null $baz) {
    …
}

Pas très lisible n’est-ce pas ? Nous verrons bien ce que cela donne avec du code issu du monde réel.

Plus d’informations sur le site officiel : PHP RFC: Disjunctive Normal Form Types

Récupérer les valeurs des enums dans une constante (RFC)

Celle-ci est très simple. Je n’ai encore jamais été confronté à un cas où j’aurais besoin de faire ça, mais PHP 8.2 nous permet de récupérer la valeur d’un cas d’une énumération directement à l’intérieur d’une constante.

enum Pokemon: string {
    case bulbizarre = "Bulbizarre";
    case salameche = "Salamèche";
    case carapuce = "Carapuce";
}
 
class Kanto {
    public const POKEMON = [
        Pokemon::bulbizarre->value,
        Pokemon::salameche->value,
        Pokemon::carapuce->value,
    ];
}
 
// PHP 8.1: Fatal error: Constant expression contains invalid operations
// PHP 8.2: array(3) {
//   [0]=>
//   string(10) "Bulbizarre"
//   [1]=>
//   string(10) "Salamèche"
//   [2]=>
//   string(8) "Carapuce"
// }
var_dump(Kanto::POKEMON);

Plus d’informations sur le site officiel : PHP RFC: Fetch properties of enums in const expressions

Vous n’êtes pas familiers avec les énumérations ? Apprenez-en les bases : minimisez les étourderies avec les énumérations dans PHP 8.1

Ajout des constantes dans les Traits (RFC)

Si vous êtes utilisateur de Laravel, vous connaissez bien le goût prononcé du framework pour l’utilisation des traits. Un trait permet d’étoffer une ou plusieurs classes avec des propriétés et des méthodes. Il n’y a pas de limites au nombre de traits que vous pouvez utiliser par classe. À partir de PHP 8.2, nous pourrons aussi ajouter des constantes dans la balance :

trait BuveurInvetere {
    public const MINIMUM = 5;
 
    public function boire() {
        …
    }
}
 
class Homer {
    use BuveurInvetere;
}
 
class Barney {
    use BuveurInvetere;
}

Plus d’informations sur le site officiel : PHP RFC: Constants in Traits

Conclusion

J’espère que le contenu de cet article vous aura plus et qu’il vous poussera à faire cette mise à jour très importante. Si vous avez le moindre problème à comprendre l’un des points ci-dessus, demandez de l’aide dans les commentaires !

Continuez votre lecture et devenez un expert en PHP :

• Minimisez les étourderies avec les énumérations dans PHP 8.1
• Soyez plus efficace grâce à switch en PHP
• Traversez les dimensions avec les tableaux en PHP