Quoi de neuf dans PHP 8.2 – Nouvelles fonctionnalités, dépréciations, changements et autres

PHP 8.2 s’appuie sur les nouvelles bases établies par PHP 8.0 et PHP 8.1. Maintenant que PHP 8.2 est sorti, nous allons couvrir les nouveautés de PHP 8.2 en détail – depuis ses nouvelles fonctionnalités et améliorations jusqu’aux dépréciations et changements mineurs, nous allons tout passer en revue.

Comme PHP 8.2 est entré dans sa période de gel des fonctionnalités le 19 juillet 2022, vous pouvez vous attendre à aucun ajout significatif à cette liste.

Excité ? Nous le sommes aussi.

C’est parti !

Nouvelles fonctionnalités et améliorations de PHP 8.2

Commençons par explorer toutes les dernières fonctionnalités de PHP 8.2. C’est une liste assez longue :

Nouvelles classes readonly

PHP 8.1 a introduit la fonctionnalitéreadonly pour les propriétés des classes. Maintenant, PHP 8.2 ajoute le support pour déclarer la classe entière comme readonly.

Si vous déclarez une classe comme readonly, toutes ses propriétés hériteront automatiquement de la fonctionnalité readonly. Ainsi, déclarer une classe readonly revient à déclarer chaque propriété de classe comme readonly.

Par exemple, avec PHP 8.1, vous deviez écrire ce code fastidieux pour déclarer toutes les propriétés de classe comme readonly:

class MyClass
{
public readonly string $myValue,
public readonly int $myOtherValue
public readonly string $myAnotherValue
public readonly int $myYetAnotherValue
}

Imaginez la même chose avec beaucoup plus de propriétés. Maintenant, avec PHP 8.2, vous pouvez simplement écrire ceci :

readonly class MyClass
{
public string $myValue,
public int $myOtherValue
public string $myAnotherValue
public int $myYetAnotherValue
}

Vous pouvez également déclarer des classes abstraites ou finales comme readonly. Ici, l’ordre des mots-clés n’a pas d’importance.

abstract readonly class Free {}
final readonly class Dom {}

Vous pouvez également déclarer une classe readonly sans propriétés. Effectivement, cela empêche les propriétés dynamiques tout en permettant aux classes filles de déclarer explicitement leurs propriétés readonly.

Ensuite, les classes readonly ne peuvent contenir que des propriétés typées – la même règle s’applique à la déclaration des propriétés individuelles readonly.

Vous pouvez utiliser la propriété de type mixed si vous ne pouvez pas déclarer une propriété strictement typée.

Si vous essayez de déclarer une classe readonly sans propriété typée, vous obtiendrez une erreur fatale :

readonly class Type {
    public $nope;
}
Fatal error: Readonly property Type::$nope must have type in ... on line ... 

De plus, vous ne pouvez pas déclarer readonly pour certaines fonctionnalités de PHP :

• Enums (car ils ne peuvent contenir aucune propriété)
• Traits
• Interfaces

Tenter de déclarer l’une de ces fonctionnalités comme readonly entraînera une erreur d’analyse.

readonly interface Destiny {}
Parse error: syntax error, unexpected token "interface", expecting "abstract" or "final" or "readonly" or "class" in ... on line ...

Comme c’est le cas pour tous les mots-clés PHP, le mot-clé readonly n’est pas sensible à la casse.

PHP 8.2 déprécie également les propriétés dynamiques (nous y reviendrons plus tard). Mais vous ne pouvez pas empêcher les propriétés dynamiques d’être ajoutées à une classe. Cependant, si vous le faites pour une classe readonly, vous obtiendrez une erreur fatale.

Fatal error: Readonly property Test::$test must have type in ... on line ...

Autoriser true, false, et null comme types autonomes

PHP inclut déjà des types scalaires comme int, string, et bool. Cela a été étendu dans PHP 8.0 avec l’ajout de types union, permettant aux valeurs d’être de différents types. La même RFC autorise également l’utilisation de false et null comme partie d’un type union – ils ne sont pas autorisés comme types autonomes, cependant.

Si vous essayez de déclarer false ou null en tant que types autonomes – sans qu’ils fassent partie d’un type d’union – vous obtenez une erreur fatale.

function spam(): null {}
function eggs(): false {}

Fatal error: Null can not be used as a standalone type in ... on line ...
Fatal error: False can not be used as a standalone type in ... on line ...

Pour éviter ce scénario, PHP 8.2 ajoute la possibilité d’utiliser false et null comme types autonomes. Avec cet ajout, le système de type de PHP est plus expressif et plus complet. Vous pouvez maintenant déclarer précisément les types de retour, de paramètre et de propriété.

De plus, PHP n’inclut toujours pas de type true, qui semble être la contrepartie naturelle du type false. PHP 8.2 corrige cela et ajoute également le support du type true. Il ne permet pas la coercition, exactement comme le type false.

Les deux types true et false sont essentiellement un type d’union du type bool de PHP. Pour éviter toute redondance, vous ne pouvez pas déclarer ces trois types ensemble dans un type union. Cela entraînerait une erreur fatale à la compilation.

Types de forme normale disjonctive (DNF)

La forme normale disjonctive (Disjunctive Normal Form ou DNF) est un moyen normalisé d’organiser les expressions booléennes. Elle consiste en une disjonction de conjonctions – en termes booléens, c’est un OR de AND.

L’application de la DNF aux déclarations de type permet d’écrire de manière standard des  types combinés Union et Intersection que l’analyseur peut gérer. La nouvelle fonctionnalité de types DNF de PHP 8.2 est simple mais puissante si elle est utilisée correctement.

La RFC donne l’exemple suivant. Il suppose que les définitions d’interface et de classe suivantes existent déjà :

interface A {}
interface B {}
interface C extends A {}
interface D {}

class W implements A {}
class X implements B {}
class Y implements A, B {}
class Z extends Y implements C {}

Avec les types DNF, vous pouvez effectuer des déclarations de type pour les propriétés, les paramètres et les valeurs de retour comme suit :

// Accepts an object that implements both A and B,
// OR an object that implements D
(A&B)|D

// Accepts an object that implements C, 
// OR a child of X that also implements D,
// OR null
C|(X&D)|null

// Accepts an object that implements all three of A, B, and D, 
// OR an int, 
// OR null.
(A&B&D)|int|null

Dans certains cas, les propriétés peuvent ne pas être sous des formes DNF. Les déclarer comme telles entraînera une erreur d’analyse. Mais vous pouvez toujours les réécrire comme :

A&(B|D)
// Can be rewritten as (A&B)|(A&D)

A|(B&(D|W)|null)
// Can be rewritten as A|(B&D)|(B&W)|null

Vous devez noter que chaque segment d’un type DNF doit être unique. Par exemple, déclarer (A&B)|(B&A) n’est pas valable car les deux segments OR sont logiquement les mêmes.

De plus, les segments qui sont des sous-ensembles stricts d’un autre segment ne sont pas autorisés non plus. En effet, le sur-ensemble contient déjà toutes les instances du sous-ensemble, ce qui rend l’utilisation de la DNF superflue.

Expurgez les paramètres sensibles dans les Back Traces

Comme presque tous les langages de programmation, PHP permet de tracer sa pile d’appels à tout moment de l’exécution du code. Le traçage de la pile facilite le débogage du code pour corriger les erreurs et les goulots d’étranglement des performances. Il constitue l’épine dorsale d’outils comme Kinsta APM, notre outil de surveillance des performances conçu sur mesure pour les sites WordPress.

L’exécution d’un suivi de pile n’interrompt pas l’exécution du programme. Généralement, la plupart des traces de pile s’exécutent en arrière-plan et sont enregistrées silencieusement – pour une inspection ultérieure si nécessaire.

Cependant, certaines de ces traces de pile PHP détaillées peuvent constituer un inconvénient si vous les partagez avec des services tiers – généralement pour l’analyse des journaux d’erreurs, le suivi des erreurs, etc. Ces traces de pile peuvent inclure des informations sensibles telles que des noms d’utilisateur, des mots de passe et des variables d’environnement.

Cette proposition de RFC donne un tel exemple :

Un « contrevenant » commun est PDO qui prend le mot de passe de la base de données comme paramètre de constructeur et tente immédiatement de se connecter à la base de données dans le constructeur, au lieu d’avoir un constructeur pur et une méthode ->connect() séparée. Ainsi, lorsque la connexion à la base de données échoue, la trace de la pile comprendra le mot de passe de la base de données :

PDOException: SQLSTATE[HY000] [2002] No such file or directory in /var/www/html/test.php:3
Stack trace: #0 /var/www/html/test.php(3): PDO->__construct('mysql:host=loca...', 'root', 'password')
#1 {main}

PHP 8.2 vous permet de marquer de tels paramètres sensibles avec un nouvel attribut \SensitiveParameter. Tout paramètre marqué sensible ne sera pas listé dans vos back traces. Ainsi, vous pouvez les partager sans soucis avec des services tiers.

Voici un exemple simple avec un seul paramètre sensible :

<?php

function example(
    $ham,
    #[\SensitiveParameter] $eggs,
    $butter
) {
    throw new \Exception('Error');
}

example('ham', 'eggs', 'butter');

/*
Fatal error: Uncaught Exception: Error in test.php:8
Stack trace:
#0 test.php(11): test('ham', Object(SensitiveParameterValue), 'butter')
#1 {main}
thrown in test.php on line 8
*/

Lorsque vous générez une trace arrière, tout paramètre avec l’attribut \SensitiveParameter sera remplacé par un objet \SensitiveParameterValue, et sa valeur réelle ne sera jamais stockée dans la trace. L’objet SensitiveParameterValue encapsule la valeur réelle du paramètre – si vous en avez besoin pour une raison quelconque.

Nouvelle fonction mysqli_execute_query et méthode mysqli::execute_query

Avez-vous déjà utilisé la fonction mysqli_query() avec des valeurs utilisateur dangereusement échappées, juste pour exécuter une requête MySQLi paramétrée ?

PHP 8.2 facilite l’exécution des requêtes MySQLi paramétrées avec la nouvelle fonction mysqli_execute_query($sql, $params) et la méthode mysqli::execute_query.

Essentiellement, cette nouvelle fonction est une combinaison des fonctions mysqli_prepare(), mysqli_execute(), et mysqli_stmt_get_result(). Avec elle, la requête MySQLi sera préparée, liée (si vous passez des paramètres) et exécutée au sein même de la fonction. Si la requête s’exécute correctement, elle renvoie un objet mysqli_result. En cas d’échec, elle renverra false.

La proposition RFC donne un exemple simple mais puissant :

foreach ($db->execute_query('SELECT * FROM user WHERE name LIKE ? AND type_id IN (?, ?)', [$name, $type1, $type2]) as $row) {
print_r($row);
}

Récupérer les propriétés de enum dans les expressions const

Ce RFC propose d’autoriser l’opérateur ->/?-> à récupérer des enum propriétés dans les expressions const.

La raison principale de cette nouvelle fonctionnalité est que vous ne pouvez pas utiliser les objets enum à certains endroits, comme les clés de tableaux. Dans un tel cas, vous devrez répéter la valeur de l’affaire enum juste pour l’utiliser.

Permettre la récupération des propriétés enum dans des endroits où les objets enum ne sont pas autorisés peut simplifier cette procédure.

Cela signifie que le code suivant est désormais valable :

const C = [self::B->value => self::B];

Et juste pour être sûr, ce RFC inclut également le support de l’opérateur nullsafe ?->.

Autoriser les constantes dans les Traits

PHP inclut un moyen de réutiliser le code appelé Traits. Ils sont parfaits pour réutiliser le code entre les classes.

Actuellement, les Traits permettent seulement de définir des méthodes et des propriétés, mais pas des constantes. Cela signifie que vous ne pouvez pas définir les invariants attendus par un Trait dans le Trait lui-même. Pour contourner cette limitation, vous devez définir les constantes dans sa classe de composition ou dans une interface implémentée par sa classe de composition.

Ce RFC propose d’autoriser la définition de constantes dans les Traits. Ces constantes peuvent être définies comme vous le feriez pour des constantes de classe. Cet exemple tiré directement du RFC clarifie les choses quant à son utilisation :

trait Foo {
    public const FLAG_1 = 1;
    protected const FLAG_2 = 2;
    private const FLAG_3 = 2;

    public function doFoo(int $flags): void {
        if ($flags & self::FLAG_1) {
            echo 'Got flag 1';
        }
        if ($flags & self::FLAG_2) {
            echo 'Got flag 2';
        }
        if ($flags & self::FLAG_3) {
        echo 'Got flag 3';
        }
    }
}

Les constantes de Trait sont également fusionnées dans la définition de la classe qui les compose, de la même manière que les définitions de propriétés et de méthodes d’un Trait. Elles ont également les mêmes restrictions que les propriétés des Traits. Comme indiqué dans la RFC, cette proposition – bien qu’elle soit un bon début – nécessite un travail supplémentaire pour étoffer cette fonctionnalité.

Dépréciations dans PHP 8.2

Nous pouvons maintenant passer à l’exploration de toutes les dépréciations de PHP 8.2. Cette liste n’est pas aussi longue que celle des nouvelles fonctionnalités :

Dépréciation des propriétés dynamiques (et nouvel attribut #[AllowDynamicProperties] )

Jusqu’à PHP 8.1, vous pouviez définir et récupérer dynamiquement des propriétés de classe non déclarées en PHP. Par exemple :

class Post {
    private int $pid;
}

$post = new Post();
$post->name = 'Kinsta';

Ici, la classe Post ne déclare pas une propriété name. Mais parce que PHP autorise les propriétés dynamiques, vous pouvez la définir en dehors de la déclaration de la classe. C’est son plus grand – et peut-être, le seul – avantage.

Les propriétés dynamiques permettent l’apparition de bogues et de comportements inattendus dans votre code. Par exemple, si vous faites une erreur en déclarant une propriété de classe en dehors de la classe, il est facile d’en perdre la trace – surtout lors du débogage d’éventuelles erreurs dans cette classe.

À partir de PHP 8.2, les propriétés dynamiques sont dépréciées. Définir une valeur à une propriété de classe non déclarée émettra une notification de dépréciation la première fois que la propriété sera définie.

class Foo {}
$foo = new Foo;

// Deprecated: Creation of dynamic property Foo::$bar is deprecated
$foo->bar = 1;

// No deprecation warning: Dynamic property already exists.
$foo->bar = 2;

Cependant, à partir de PHP 9.0, la définition de la même valeur entraînera une erreur ErrorException.

Si votre code est rempli de propriétés dynamiques – et c’est le cas de beaucoup de code PHP – et si vous voulez arrêter ces avis de dépréciation après la mise à jour vers PHP 8.2, vous pouvez utiliser le nouvel attribut #[AllowDynamicProperties] de PHP 8.2 pour autoriser les propriétés dynamiques sur les classes.

#[AllowDynamicProperties]
class Pets {}
class Cats extends Pets {}

// You'll get no deprecation warning
$obj = new Pets;
$obj->test = 1;

// You'll get no deprecation warning for child classes
$obj = new Cats;
$obj->test = 1;

Selon la RFC, les classes marquées comme #[AllowDynamicProperties], ainsi que leurs classes filles, peuvent continuer à utiliser les propriétés dynamiques sans dépréciation ou suppression.

Vous devez également noter que, en PHP 8.2, la seule classe marquée comme #[AllowDynamicProperties] est stdClass. De plus, toutes les propriétés accédées par les méthodes magiques PHP __get() ou __set() ne sont pas considérées comme des propriétés dynamiques, de sorte qu’elles ne déclencheront pas de notification de dépréciation.

Dépréciation des appelants partiellement supportés

Un autre changement de PHP 8.2, bien qu’avec un impact plus négligeable, est de déprécier les appelables partiellement supportés.

Ces appelables sont appelés partiellement supportés parce que vous ne pouvez pas interagir avec eux directement via $callable(). Vous ne pouvez les atteindre qu’avec la fonction call_user_func($callable). La liste de ces appelables n’est pas longue :

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

À partir de PHP 8.2, toute tentative d’invoquer de tels appelables – comme via les fonctions call_user_func() ou array_map() – entraînera un avertissement de dépréciation.

La RFC originale donne un raisonnement solide derrière cette dépréciation :

En dehors des deux derniers cas, tous ces appelables 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 l’appelabilité est effectué. En pratique, cela vaut également pour les deux derniers cas, lorsqu’ils sont utilisés sous la forme de [new Foo, "parent::method"].

La réduction de la dépendance contextuelle des appelables est l’objectif secondaire de ce RFC. Après ce RFC, la seule dépendance de portée qui subsiste est la visibilité de la méthode : "Foo::bar" peut être visible dans une portée, mais pas dans une autre. Si les appelables devaient être limités aux méthodes publiques à l’avenir (tandis que les méthodes privées devraient utiliser des appelables de première classe ou Closure::fromCallable() pour être rendues indépendantes de la portée), alors le type d’appelable 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

.
Conformément au RFC d’origine, la fonction is_callable() et le type callable continueront à accepter ces appellables en tant qu’exceptions. Mais seulement jusqu’à ce que leur support soit entièrement supprimé à partir de PHP 9.0.

Pour éviter toute confusion, le champ d’application de cette notice de dépréciation a été étendu avec un nouveau RFC – il inclut maintenant ces exceptions.

C’est une bonne chose de voir PHP évoluer vers un type callable bien défini.

Dépréciation des fonctions #utf8_encode() et utf8_decode()

Les fonctions intégrées de PHP utf8_encode() et utf8_decode() convertissent les chaînes encodées en ISO-8859-1 (« Latin 1 ») en UTF-8 et vice-versa.

Cependant, leurs noms suggèrent une utilisation plus générale que leur implémentation ne le permet. L’encodage « Latin 1 » est souvent confondu avec d’autres encodages tels que le « Windows Code Page 1252 »

En outre, vous verrez généralement Mojibake lorsque ces fonctions ne peuvent pas convertir correctement une chaîne de caractères. L’absence de messages d’erreur signifie également qu’il est difficile de les repérer, surtout au milieu d’une mer de texte autrement lisible.

PHP 8.2 déprécie les fonctions #utf8_encode() et utf8_decode() . Si vous les invoquez, vous verrez ces avis de dépréciation :

Deprecated: Function utf8_encode() is deprecated
Deprecated: Function utf8_decode() is deprecated

La RFC suggère d’utiliser les extensions supportées par PHP comme mbstring, iconv, et intl à la place.

Dépréciation de ${} Interpolation de chaînes de caractères

PHP permet d’intégrer des variables dans des chaînes de caractères avec des guillemets doubles (") et heredoc (<<<) de plusieurs façons :

1. Variables directement incorporées – “$foo”
2. Avec des accolades à l’extérieur de la variable – “{$foo}”
3. Avec des accolades après le signe dollar – “${foo}”
4. Variables variables – “${expr}” – équivalent à l’utilisation de (string) ${expr}

Les deux premières façons ont leurs avantages et leurs inconvénients, tandis que les deux dernières ont une syntaxe complexe et conflictuelle. PHP 8.2 déprécie les deux dernières méthodes d’interpolation de chaînes de caractères.

Vous devriez éviter d’interpoler des chaînes de cette façon à l’avenir :

"Hello, ${world}!";
Deprecated: Using ${} in strings is deprecated

"Hello, ${(world)}!";
Deprecated: Using ${} (variable variables) in strings is deprecated

À partir de PHP 9.0, ces dépréciations seront mises à jour pour lancer une exception d’erreur.

Dépréciation des fonctions mbstring pour les entités Base64/QPrint/Uuencode/HTML

Les fonctions mbstring (chaîne de caractères multi-octets) de PHP nous aident à travailler avec l’Unicode, les entités HTML, et d’autres encodages de texte anciens.

Cependant, Base64, Uuencode, et QPrint ne sont pas des encodages de texte et font toujours partie de ces fonctions – principalement pour des raisons d’héritage. PHP inclut également des implémentations séparées de ces encodages.

Quant aux entités HTML, PHP a des fonctions intégrées – htmlspecialchars() et htmlentities() – pour mieux les gérer. Par exemple, contrairement à mbstring, ces fonctions convertiront également <. > et & en entités HTML.

De plus, PHP améliore constamment ses fonctions intégrées – comme PHP 8.1 avec les fonctions d’encodage et de décodage HTML.

Donc, en gardant tout cela à l’esprit, PHP 8.2 déprécie l’utilisation de mbstring pour ces encodages (les libellés sont insensibles à la casse) :

• BASE64
• UUENCODE
• HTML-ENTITIES
• html (alias de HTML-ENTITIES)
• Quoted-Printable
• qprint (alias de Quoted-Printable)

A partir de PHP 8.2, l’utilisation de mbstring pour encoder/décoder l’un des éléments ci-dessus émettra une notification de dépréciation. PHP 9.0 supprimera complètement le support de mbstring pour ces encodages.

Autres changements mineurs dans PHP 8.2

Enfin, nous pouvons aborder les changements mineurs de PHP 8.2, y compris les caractéristiques et fonctionnalités supprimées.

Suppression du support de libmysql de mysqli

A partir de maintenant, PHP permet aux pilotes mysqli et PDO_mysql de construire contre les bibliothèques mysqlnd et libmysql. Cependant, le pilote par défaut et recommandé depuis PHP 5.4 est mysqlnd.

Ces deux pilotes ont de nombreux avantages et inconvénients. Cependant, supprimer le support de l’un d’entre eux – idéalement, supprimer libmysql car il n’est pas le pilote par défaut – simplifiera le code et les tests unitaires de PHP.

Pour argumenter en faveur de cette faveur, le RFC liste de nombreux avantages de mysqlnd:

• Il est fourni avec PHP
• Il utilise la gestion de la mémoire de PHP pour surveiller l’utilisation de la mémoire et
  améliorer les performances
• Fournit des fonctions de qualité de vie (par exemple, get_result())
• Renvoie des valeurs numériques en utilisant les types natifs de PHP
• Ses fonctionnalités ne dépendent pas de la bibliothèque externe
• Fonctionnalité d’extension optionnelle
• Supporte les requêtes asynchrones

La RFC liste également quelques avantages de libmysql, dont :

• La reconnexion automatique est possible ( mysqlnd ne supporte pas cette fonctionnalité intentionnellement car elle peut être facilement exploitée)
• Modes d’authentification LDAP et SASL (mysqlnd pourrait ajouter cette fonctionnalité prochainement aussi)

En outre, le RFC énumère de nombreux inconvénients de libmysql – incompatibilité avec le modèle de mémoire de PHP, nombreux tests échoués, fuites de mémoire, différences de fonctionnalités entre les versions, etc.

En gardant tout cela à l’esprit, PHP 8.2 a supprimé le support de la construction de mysqli contre libmysql.

Si vous voulez ajouter une fonctionnalité qui n’est disponible qu’avec libmysql, vous devrez l’ajouter explicitement à mysqlnd en tant que demande de fonctionnalité. De même, vous ne pouvez pas ajouter l’auto-reconnexion.

Conversion des cas indépendants de la localisation

Avant PHP 8.0, la locale de PHP était héritée de l’environnement système. Mais cela pouvait causer un problème dans certains cas limites.

Le fait de définir votre langue lors de l’installation de Linux va définir la langue appropriée de l’interface utilisateur pour ses commandes intégrées. Cependant, cela modifie aussi de manière inattendue le fonctionnement de la fonctionnalité de traitement des chaînes de caractères de la bibliothèque C.

Par exemple, si vous avez sélectionné la langue « turque » ou « kazakhe » lors de l’installation de Linux, vous constaterez que l’appel de toupper('i') pour obtenir son équivalent en majuscules obtiendra le I majuscule pointé (U+0130, İ).

PHP 8.0 a mis fin à cette anomalie en fixant la locale par défaut à « C », sauf si l’utilisateur la modifie explicitement via setlocale().

PHP 8.2 va encore plus loin en supprimant la sensibilité locale des conversions de casse. Cette RFC modifie principalement strtolower(), strtoupper(), et les fonctions associées. Lisez la RFC pour obtenir la liste de toutes les fonctions concernées.

Comme alternative, si vous voulez utiliser la conversion de casse localisée, vous pouvez utiliser mb_strtolower().

Amélioration de l’extension aléatoire

PHP prévoit de remanier sa fonctionnalité aléatoire.

Actuellement, la fonctionnalité aléatoire de PHP repose sur l’état de Mersenne Twister. Cependant, cet état est implicitement stocké dans la zone globale de PHP – il n’y a aucun moyen pour un utilisateur d’y accéder. L’ajout de fonctions aléatoires entre l’étape initiale d’ensemencement et l’utilisation prévue briserait le code.

La maintenance d’un tel code peut être encore plus compliquée lorsque votre code utilise des paquets externes.

Ainsi, la fonctionnalité aléatoire actuelle de PHP ne peut pas reproduire des valeurs aléatoires de manière cohérente. Elle échoue même aux tests statistiques empiriques des générateurs de nombres aléatoires uniformes, comme Crush et BigCrush de TestU01. La limitation à 32 bits de Mersenne Twister aggrave encore la situation.

Ainsi, l’utilisation des fonctions intégrées de PHP – shuffle(), str_shuffle(), array_rand() – n’est pas recommandée si vous avez besoin de nombres aléatoires crypto-graphiquement sécurisés. Dans ce cas, vous devrez implémenter une nouvelle fonction en utilisant random_int() ou des fonctions similaires.

Cependant, plusieurs problèmes avec cette RFC ont été soulevés après que le vote ait commencé. Ce contretemps a obligé l’équipe PHP à noter tous les problèmes dans une RFC séparée, avec une option de vote créée pour chaque problème. Ils décideront d’aller plus loin seulement après avoir atteint un consensus.

RFC supplémentaires dans PHP 8.2

PHP 8.2 inclut également de nombreuses nouvelles fonctions et des changements mineurs. Nous les mentionnons ci-dessous avec des liens vers des ressources supplémentaires :

1. Nouvelle fonction curl_upkeep : PHP 8.2 ajoute cette nouvelle fonction à son extension Curl. Elle appelle la fonction curl_easy_upkeep() dans libcurl, la bibliothèque C sous-jacente que l’extension Curl de PHP utilise.
2. Nouvelle fonction ini_parse_quantity : Les directives PHP INI acceptent les tailles de données avec un suffixe multiplicateur. Par exemple, vous pouvez écrire 25 mégaoctets comme 25M, ou 42 gigaoctets comme 42G. Ces suffixes sont courants dans les fichiers PHP INI mais sont rares ailleurs. Cette nouvelle fonction analyse les valeurs PHP INI et renvoie leur taille en octets.
3. Nouvelle fonction memory_reset_peak_usage : Cette fonction réinitialise l’utilisation maximale de la mémoire retournée par la fonction memory_get_peak_usage. Elle peut être pratique lorsque vous exécutez la même action plusieurs fois et que vous souhaitez enregistrer l’utilisation maximale de la mémoire pour chaque exécution.
4. Prise en charge du modificateur de non-capture (/n) dans les fonctions preg_* : En regex, les métacaractères () indiquent un groupe de capture. Cela signifie que toutes les correspondances de l’expression entre les crochets sont retournées. PHP 8.2 ajoute un modificateur de non capture (/n) pour arrêter ce comportement.
5. Faites en sorte que la famille iterator_*() accepte tous les itérables: Pour l’instant, la famille iterator_*() de PHP n’accepte que \Traversables (c’est-à-dire qu’aucun tableau n’est autorisé). C’est inutilement restrictif, et ce RFC corrige cela.

Résumé

PHP 8.2 s’appuie sur les améliorations massives de PHP 8.0 et PHP 8.1, ce qui n’est pas une mince affaire. Nous pensons que les fonctionnalités les plus intéressantes de PHP 8.2 sont ses nouveaux types autonomes, ses propriétés en lecture seule, et ses nombreuses améliorations de performances.

Nous sommes impatients d’évaluer PHP 8.2 avec différents frameworks PHP et CMS.

N’oubliez pas d’ajouter cet article de blog à vos favoris pour vous y référer ultérieurement.

Quelles sont les fonctionnalités de PHP 8.2 que vous préférez ? Quelles sont les dépréciations que vous préférez le moins ? Partagez vos réflexions avec notre communauté dans les commentaires !