Quoi de neuf dans PHP 8.2 — Nouvelles fonctionnalités, obsolescences, modifications, etc.

Publié: 2022-08-09

PHP 8.2 s'appuie sur la base renouvelée établie par PHP 8.0 et PHP 8.1. Il est prévu de sortir le 24 novembre 2022.

Cet article couvrira en détail les nouveautés de PHP 8.2 - de ses nouvelles fonctionnalités et améliorations aux obsolescences et modifications mineures, nous les passerons toutes en revue.

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

Excité? Étions aussi.

Commençons!

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 en readonly

PHP 8.1 a introduit la fonctionnalité de readonly pour les propriétés de classe. 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 en 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 en 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 en readonly sans propriétés. En fait, cela empêche les propriétés dynamiques tout en permettant aux classes enfants de déclarer explicitement leurs propriétés en readonly .

Ensuite, les classes en readonly ne peuvent contenir que des propriétés typées - la même règle pour déclarer des propriétés en lecture seule individuelles.

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

Essayer de déclarer une classe en readonly sans propriété typée entraînera 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 PHP :

  • Énumérations (car elles ne peuvent contenir aucune propriété)
  • Traits
  • Interfaces

Tenter de déclarer l'une de ces fonctionnalités en 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 est insensible à la casse.

PHP 8.2 déprécie également les propriétés dynamiques (nous en reparlerons plus tard). Mais vous ne pouvez pas empêcher l'ajout de propriétés dynamiques à une classe. Cependant, le faire pour une classe en readonly n'entraînera qu'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 d'union, permettant aux valeurs d'être de types différents. La même RFC autorisait également l'utilisation de false et null dans le cadre d'un type d'union - ils n'étaient cependant pas autorisés en tant que types autonomes.

Si vous avez essayé de déclarer false ou null ou en tant que types autonomes - sans qu'ils fassent partie d'un type union - cela entraînait 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 prise en charge de l'utilisation de false et null en tant que types autonomes. Avec cet ajout, le système de type de PHP est plus expressif et 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 true type, qui semble être une contrepartie naturelle du false type. PHP 8.2 corrige cela et ajoute également la prise en charge du true type. Il ne permet pas la coercition, exactement comme le comportement du type false .

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

Types de forme normale disjonctive (DNF)

La forme normale disjonctive (DNF) est une manière standardisée d'organiser les expressions booléennes. Il consiste en une disjonction de conjonctions - en termes booléens, c'est un OU de ET .

L'application de DNF aux déclarations de type permet d'écrire de manière standard des types Union et Intersection combinés 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 dans les formulaires DNF. Les déclarer comme tels entraînera une erreur d'analyse. Mais vous pouvez toujours les réécrire comme suit :

 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

Notez que chaque segment d'un type DNF doit être unique. Par exemple, déclarer (A&B)|(B&A) n'est pas valide car les deux segments OR sont logiquement identiques.

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

Masquer les paramètres sensibles dans les traces arrière

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 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.

Suivi des transactions WooCommerce lentes via l'outil Kinsta APM.
Suivi des transactions WooCommerce lentes avec Kinsta APM.

L'exécution d'une trace de pile n'interrompt pas l'exécution du programme. En règle générale, la plupart des traces de pile s'exécutent en arrière-plan et sont consignées en mode silencieux, pour une inspection ultérieure si nécessaire.

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

Cette proposition RFC en donne un exemple :

Un "délinquant" courant est PDO qui prend le mot de passe de la base de données comme paramètre du 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 inclura 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 ces paramètres sensibles avec un nouvel attribut \SensitiveParameter . Tout paramètre marqué sensible ne sera pas listé dans vos backtraces. 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, 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 s'échappant dangereusement 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 mysqli_execute_query($sql, $params) et la méthode mysqli::execute_query .

Essentiellement, cette nouvelle fonction est une combinaison des mysqli_prepare() , mysqli_execute() et mysqli_stmt_get_result() . Avec lui, la requête MySQLi sera préparée, liée (si vous passez des paramètres) et exécutée dans la fonction elle-même. Si la requête s'exécute avec succès, elle renverra un objet mysqli_result . En cas d'échec, il retournera 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 enum dans les expressions const

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

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

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

Cela signifie que le code suivant est maintenant valide :

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

Et juste pour être sûr, cette RFC inclut également la prise en charge 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 la réutilisation du code dans les classes.

Actuellement, les traits permettent uniquement 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 des constantes dans sa classe de composition ou une interface implémentée par sa classe de composition.

Cette RFC propose de permettre la définition de constantes dans Traits. Ces constantes peuvent être définies comme vous définiriez des constantes de classe. Cet exemple tiré directement de la RFC clarifie l'air autour de 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 de composition, de la même manière que les définitions de propriété et de méthode d'un trait. Ils ont également des restrictions similaires à celles des propriétés des traits. Comme indiqué dans la RFC, cette proposition - bien qu'un bon début - nécessite des travaux supplémentaires pour étoffer la fonctionnalité.

Dépréciations en PHP 8.2

Nous pouvons maintenant explorer toutes les dépréciations de PHP 8.2. Cette liste n'est pas aussi grande que ses 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 dans PHP. Par exemple:

 class Post { private int $pid; } $post = new Post(); $post->name = 'Kinsta';

Ici, la classe Post ne déclare pas de propriété name . Mais comme PHP autorise les propriétés dynamiques, vous pouvez les définir en dehors de la déclaration de 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 lors de la déclaration d'une propriété de classe en dehors de la classe, il est facile de la perdre de vue, en particulier lors du débogage d'erreurs au sein de cette classe.

Depuis PHP 8.2, les propriétés dynamiques sont obsolètes. La définition d'une valeur sur une propriété de classe non déclarée émettra un avis d'obsolescence la première fois que la propriété est 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, définir la même chose générera une erreur ErrorException .

Si votre code est plein de propriétés dynamiques - et il y a beaucoup de code PHP - et si vous voulez arrêter ces avis de dépréciation après la mise à niveau vers PHP 8.2, vous pouvez utiliser le nouvel attribut #[AllowDynamicProperties] de PHP 8.2 pour autoriser dynamique propriétés 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;

Conformément à la RFC, les classes marquées comme #[AllowDynamicProperties] , ainsi que leurs classes enfants, peuvent continuer à utiliser des propriétés dynamiques sans obsolescence ni suppression.

Vous devez également noter que, dans PHP 8.2, la seule classe groupée marquée comme #[AllowDynamicProperties] est stdClass . De plus, toutes les propriétés accessibles via 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 génèrent pas d'avis de dépréciation.

Abandonner les callables partiellement pris en charge

Un autre changement de PHP 8.2, bien qu'avec un impact plus négligeable, consiste à déprécier les callables partiellement pris en charge.

Ces callables sont appelés partiellement pris en charge car vous ne pouvez pas interagir avec eux directement via $callable() . Vous ne pouvez y accéder qu'avec la call_user_func($callable) . La liste de ces callables 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'invocation de tels callables - comme via les fonctions call_user_func() ou array_map() - lancera un avertissement de dépréciation.

Le RFC d'origine donne un raisonnement solide derrière cette dépréciation :

Hormis les deux derniers cas, tous ces callables dépendent 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 capacité d'appel est effectuée. En pratique, cela vaut généralement aussi pour les deux derniers cas, lorsqu'ils sont utilisés sous la forme de [new Foo, "parent::method"] .

Réduire la dépendance au contexte des callables est l'objectif secondaire de cette RFC. Après cette RFC, la seule dépendance à la 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 (alors que les méthodes privées devraient utiliser des callables de première classe ou Closure::fromCallable() pour être indépendantes de la portée), alors le type callable deviendrait bien défini et pourrait être utilisé comme type de propriété. Cependant, les modifications de la gestion de la visibilité ne sont pas proposées dans le cadre de cette RFC .

Selon la RFC d'origine, la fonction is_callable() et le type callable continueront d'accepter ces callables comme exceptions. Mais seulement jusqu'à ce que leur prise en charge soit entièrement supprimée à partir de PHP 9.0.

Pour éviter toute confusion, la portée de cet avis d'obsolescence a été étendue avec une nouvelle RFC — elle inclut désormais ces exceptions.

Il est bon de voir PHP évoluer vers un type callable bien défini.

#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") vers et depuis UTF-8.

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

De plus, vous verrez généralement Mojibake lorsque ces fonctions ne peuvent convertir aucune chaîne correctement. L'absence de messages d'erreur signifie également qu'il est difficile de les repérer, en particulier dans une mer de texte autrement lisible.

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

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

La RFC suggère d'utiliser à la place les extensions prises en charge par PHP telles que mbstring , iconv et intl .

Abandon de l'interpolation de chaîne ${}

PHP permet d'intégrer des variables dans des chaînes avec des guillemets doubles ( " ) et heredoc ( <<< ) de plusieurs manières :

  1. Intégrer directement des variables — “$foo”
  2. Avec des accolades en dehors 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 méthodes ont leurs avantages et leurs inconvénients, tandis que les deux dernières ont une syntaxe complexe et contradictoire. PHP 8.2 déconseille les deux dernières méthodes d'interpolation de chaîne.

Vous devriez éviter d'interpoler les 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 générer une erreur d'exception.

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

Les fonctions mbstring (chaîne multi-octets) de PHP nous aident à travailler avec Unicode, les entités HTML et d'autres encodages de texte hérités.

Cependant, Base64, Uuencode et QPrint ne sont pas des encodages de texte et font toujours partie de ces fonctions, principalement pour des raisons héritées. PHP inclut également des implémentations distinctes de ces encodages.

En ce qui concerne les 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 & caractères aux entités HTML.

De plus, PHP améliore constamment ses fonctions intégrées, tout comme PHP 8.1 avec des fonctions d'encodage et de décodage HTML.

Donc, en gardant tout cela à l'esprit, PHP 8.2 déconseille l'utilisation de mbstring pour ces encodages (les étiquettes ne sont pas sensibles à la casse) :

  • BASE64
  • UUENCODE
  • HTML-ENTITÉS
  • html (alias de HTML-ENTITIES)
  • Cité-Imprimable
  • qprint (alias de Quoted-Printable)

À partir de PHP 8.2, l'utilisation de mbstring pour encoder/décoder l'un des éléments ci-dessus émettra un avis de dépréciation. PHP 9.0 supprimera complètement la prise en charge de mbstring pour ces encodages.

Autres changements mineurs dans PHP 8.2

Enfin, nous pouvons discuter des modifications mineures de PHP 8.2, y compris ses fonctionnalités et fonctionnalités supprimées.

Supprimer la prise en charge de libmysql de mysqli

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

Ces deux moteurs présentent de nombreux avantages et inconvénients. Cependant, la suppression de la prise en charge de l'un d'entre eux - idéalement, la suppression de libmysql car ce n'est pas la valeur par défaut - simplifiera le code PHP et les tests unitaires.

Pour plaider en faveur de cette faveur, la RFC énumère de nombreux avantages de mysqlnd :

  • Il est fourni avec PHP
  • Il utilise la gestion de la mémoire 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 à l'aide de types natifs PHP
  • Sa fonctionnalité ne dépend pas de la bibliothèque externe
  • Fonctionnalité de plug-in en option
  • Prend en charge les requêtes asynchrones

La RFC énumère également certains avantages de libmysql , notamment :

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

De plus, la RFC énumère de nombreux inconvénients de libmysql — incompatibilité avec le modèle de mémoire PHP, nombreux tests défaillants, fuites de mémoire, fonctionnalités différentes entre les versions, etc.

Gardant tout cela à l'esprit, PHP 8.2 a supprimé la prise en charge de la construction de mysqli avec libmysql .

Si vous souhaitez ajouter une fonctionnalité uniquement disponible avec libmysql , vous devrez l'ajouter explicitement à mysqlnd en tant que demande de fonctionnalité. De plus, vous ne pouvez pas ajouter de reconnexion automatique.

Conversion de cas indépendante des paramètres régionaux

Avant PHP 8.0, les paramètres régionaux de PHP étaient hérités de l'environnement système. Mais cela pourrait causer un problème dans certains cas extrêmes.

La définition de votre langue lors de l'installation de Linux définira la langue d'interface utilisateur appropriée pour ses commandes intégrées. Cependant, cela modifie également de manière inattendue le fonctionnement de la fonctionnalité de gestion des chaînes de la bibliothèque C.

Par exemple, si vous avez sélectionné la langue "Turc" ou "Kazakh" lors de l'installation de Linux, vous constaterez qu'appeler toupper('i') pour obtenir son équivalent en majuscule obtiendrait la majuscule pointée I (U+0130, I ).

PHP 8.0 a arrêté cette anomalie en définissant la locale par défaut sur "C", à moins que l'utilisateur ne la modifie explicitement via setlocale() .

PHP 8.2 va encore plus loin en supprimant la sensibilité aux paramètres régionaux des conversions de casse. Cette RFC modifie principalement strtolower() , strtoupper() et les fonctions associées. Lisez le RFC pour une liste de toutes les fonctions affectées.

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

Amélioration de l'extension aléatoire

PHP prévoit de réviser sa fonctionnalité aléatoire.

À partir de maintenant, la fonctionnalité aléatoire de PHP repose fortement sur l'état 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 de randomisation entre l'étape d'amorçage initiale et l'utilisation prévue casserait le code.

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

Ainsi, la fonctionnalité aléatoire actuelle de PHP ne peut pas reproduire les valeurs aléatoires de manière cohérente. Il é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 cela.

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 cryptographiquement sécurisés. Dans de tels cas, vous devrez implémenter une nouvelle fonction en utilisant random_int() ou des fonctions similaires.

Cependant, plusieurs problèmes avec ce RFC ont été soulevés après le début du vote. Ce revers a forcé l'équipe PHP à noter tous les problèmes dans un RFC séparé, avec une option de vote créée pour chaque problème. Ils ne décideront d'aller plus loin qu'après avoir atteint un consensus.

RFC supplémentaires dans PHP 8.2

PHP 8.2 inclut également de nombreuses nouvelles fonctions et modifications mineures. Nous les mentionnerons 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. Il appelle la fonction curl_easy_upkeep() dans libcurl, la bibliothèque C sous-jacente utilisée par l'extension PHP Curl.
  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 juste 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 de données en octets.
  3. Nouvelle fonction memory_reset_peak_usage : cette fonction réinitialise le pic d'utilisation de la mémoire renvoyé par la fonction memory_get_peak_usage . Cela 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 de chaque exécution.
  4. Prise en charge du modificateur de non-capture ( /n ) dans les fonctions preg_* : dans regex, les métacaractères () indiquent un groupe de capture. Cela signifie que toutes les correspondances pour l'expression entre parenthèses sont renvoyé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 simple n'est autorisé). C'est inutilement limitant, et cette RFC corrige cela.

Sommaire

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 avons hâte de comparer PHP 8.2 avec divers frameworks PHP et CMS.

Assurez-vous de mettre cet article de blog en signet pour votre future référence.

Quelles sont les fonctionnalités de PHP 8.2 que vous préférez ? Quelles sont les dépréciations que vous aimez le moins ? S'il vous plaît partagez vos pensées avec notre communauté dans les commentaires!