PHP 8.1 : restriction de l'utilisation de $GLOBALS, notation littérale octale explicite des entiers,

Voici un aperçu des nouveautés attendues dans la prochaine version du langage

Le 2021-02-01 09:03:11, par Bill Fassinou, Chroniqueur Actualités

Alors que PHP 8 a été publié en novembre dernier, l'équipe de développement du langage travaille déjà sur la prochaine version mineure, notamment PHP 8.1. Comme chaque version de PHP, PHP 8.1 ajoute de nouvelles fonctionnalités au langage, fait quelques modifications, rend certaines fonctions obsolètes et déprécie certaines fonctions obsolètes depuis les versions précédentes. Voici ci-dessus quelques fonctionnalités connues qui pourraient être livrées avec PHP 8.1. Notez que cette nouvelle version est en cours de développement, alors d'autres fonctionnalités pourraient s'ajouter jusqu'à la date de publication, qui sera probablement en novembre.

Nouvelles fonctionnalités dans PHP 8.1

Déballage des tableaux (Array unpacking) avec des clés de chaîne

Le déballage de tableaux était déjà autorisé en PHP 7.4, mais il ne fonctionnait qu'avec des clés numériques. La raison pour laquelle les clés de chaînes n'étaient pas supportées auparavant est qu'il n'y avait pas de consensus sur la façon de fusionner les doublons de tableaux. Cette RFC résout ce problème en suivant la sémantique de "array_merge" :

Code :

1
2
3
4
5
6
7
8
$array1 = ["a" => 1];

$array2 = ["b" => 2];

$array = ["a" => 0, ...$array1, ...$array2];

var_dump($array); // ["a" => 1, "b" => 2]

Nouvelle fonction array_is_list

Vous avez probablement déjà eu à faire face à cette situation de temps en temps : déterminer si les clés d'un tableau sont dans l'ordre numérique, en commençant par l'index 0. Tout comme "json_encode" décide si un tableau doit être encodé comme un tableau ou un objet, PHP 8.1 ajoute une fonction intégrée pour déterminer si un tableau est une liste avec cette sémantique, ou non. En d'autres termes, cette fonction retourne "true" si le tableau donné est une liste sémantique de valeurs ; un tableau où toutes les clés sont des entiers, les clés commencent à 0, sans aucun espace entre elles. La fonction "array_is_list" renvoie également la valeur "true" pour les tableaux vides.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
$list = ["a", "b", "c"];

array_is_list($list); // true

$notAList = [1 => "a", 2 => "b", 3 => "c"];

array_is_list($notAList); // false

$alsoNotAList = ["a" => "a", "b" => "b", "c" => "c"];

array_is_list($alsoNotAList); // false

Notation littérale octale explicite des entiers

PHP prend en charge divers systèmes de numération, notamment le système décimal par défaut (base 10), le système binaire (base 2), le système octal (base 8) et le système hexadécimal (base 16). Les systèmes numériques autres que décimaux sont préfixés par leur propre préfixe :

Hex avec préfixe 0x : par exemple 0x11 = 17 ;
Binaire avec préfixe 0b : par exemple 0b11 = 3 ;
Octal avec le préfixe 0 : par exemple 011 = 9.

Vous pouvez maintenant utiliser 0o pour désigner les nombres octal. En effet, à partir de PHP 8.1 et pour les versions ultérieures, les chiffres octaux supportent aussi le préfixe 0o (zéro, suivi de o), ce qui signifie que les littéraux numériques octaux sont désormais rendus plus évidents et plus lisibles. Le 0O (zéro, suivi d'un O majuscule comme dans Oscar) est également pris en charge. En outre, la notation précédente en préfixant un nombre par un 0 pour indiquer qu'il s'agit d'un nombre octal fonctionne toujours aussi bien.

Enums

Cette RFC introduit les énumérations dans le langage PHP. Le champ d'application de cette RFC est limité aux "énumérations d'unités", c'est-à-dire aux énumérations qui sont elles-mêmes une valeur, plutôt qu'une simple syntaxe fantaisiste pour une constante primitive, et qui n'incluent pas d'informations supplémentaires associées. Cette capacité offre une prise en charge considérablement élargie pour la modélisation des données, les définitions de types personnalisés et le comportement de type monade.

Code :

1
2
3
4
5
6
enum Status {
  case Pending;
  case Active;
  case Archived;
}

Les énumérations permettent la technique de modélisation consistant à "rendre les états non valides non représentables", ce qui permet d'obtenir un code plus robuste et de réduire les besoins en tests exhaustifs. Les dénombrements sont construits sur la base de classes et d'objets. Cela signifie que, sauf indication contraire, "comment les Enums se comporteraient dans la situation X" peut être répondu "de la même manière que toute autre instance d'objet". Ils passeraient, par exemple, un contrôle de type d'objet.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Post
{
    public function __construct(
        private Status $status = Status::Pending;
    ) {}

    public function setStatus(Status $status): void
    {
        // …
    }
}

$post->setStatus(Status::Active);

Les noms des Enums ne sont pas sensibles à la casse, mais sont soumis à la même mise en garde concernant l'autochargement sur les systèmes de fichiers sensibles à la casse que celle qui s'applique déjà aux classes en général. Les noms de casse sont implémentés en interne comme des constantes de classe, et sont donc sensibles à la casse. Toutefois, cette RFC est toujours en cours de discussion. Même s'il n'y a pas encore eu de vote, cette proposition d'ajouter des énumérations a été reçue avec enthousiasme. L'ajout d'énumérations pourrait être une amélioration significative de PHP.

Changements de rupture

Bien que PHP 8.1 soit une version mineure, il y aura quelques changements qui pourraient techniquement être un changement de rupture, et des déprédations aussi. En voici quelques-uns.

Restreindre l'utilisation de $GLOBALS

La variable $GLOBALS fournit actuellement une référence directe à la table de symboles interne de PHP. La prise en charge de cette fonction nécessite une grande complexité technique, affecte les performances de toutes les opérations de tableau dans PHP, mais n'est que rarement utilisée. Cette RFC restreint les utilisations supportées de $GLOBALS afin de rejeter les cas problématiques, tout en permettant à la plupart du code de continuer à fonctionner tel quel. L'idée centrale de cette proposition est de faire passer $GLOBALS de variable "réelle" à sémantique non standard à une variable syntaxique à deux sémantiques :

les accès de la forme $GLOBALS [$var] feront référence à la variable globale $ $var, et supporteront toutes les opérations habituelles de la variable, y compris les écritures. $GLOBALS [$var] = la valeur $ reste supportée. Une bonne façon d'y penser est que $GLOBALS[$var] fonctionne de la même manière qu'une variable $ $var, en accédant simplement à la portée globale au lieu de la portée locale ;
les accès de la forme $GLOBALS (sans déréférencement direct du tableau) renverront une copie en lecture seule du tableau de symboles global.

Une petite modification de la manière dont $GLOBALS est utilisé aura un impact significatif sur les performances de toutes les opérations de la matrice.

Déprécier le passage de null à des arguments non annulables des fonctions internes

Les fonctions internes (définies par PHP ou ses extensions) acceptent actuellement de manière silencieuse des valeurs nulles pour les arguments non annulables en mode de frappe coercitif. Ceci est contraire au comportement des fonctions définies par l'utilisateur, qui n'acceptent que les valeurs nulles pour les arguments nuls. Cette RFC vise à résoudre cette incohérence. Voici ci-dessous de quoi il s'agit :

Si

la nullité est passée à l'argument d'une fonction interne ;
l'argument n'est pas annulable ;
l'argument accepte au moins un type scalaire (un de bool, int, float ou string) ;
le mode de frappe coercitif est utilisé, c'est-à-dire que strict_types=1 n'est pas activé ;

alors

en PHP < 8.1, la valeur nulle sera silencieusement contrainte à false, 0, 0.0 ou "" ;
en PHP >= 8.1, une erreur de dépréciation est lancée, mais la valeur est toujours contrainte et l'appel a toujours lieu ;
en PHP >= 9.0, une erreur de type (TypeError) sera déclenchée, en accord avec le comportement des fonctions définies par l'utilisateur.

Source : RFC PHP 8.1

Et vous ?

Que pensez-vous des fonctionnalités prévues pour être livrées avec PHP 8.1 ?
Quelles fonctionnalités aimeriez-vous voir apparaître dans cette version ?

Voir aussi

PHP 8 est disponible et s'accompagne d'optimisations et de nouvelles fonctionnalités, incluant entre autres les arguments nommés, les types d'union, l'opérateur nullsafe, la compilation JIT

Les nouveautés de PHP 8 - Sortie de la version alpha 1 prévue le 25 juin 2020 ! Par Alexandre Tranchant

PHP 7.4.0 est disponible avec de nombreuses améliorations et de nouvelles fonctionnalités, telles que les propriétés typées, un séparateur numérique littéral, et autres

Microsoft annonce qu'il ne va plus offrir de support à PHP sur Windows dès la version 8.0, dont la sortie est prévue pour novembre

Discussion forum

13 commentaires

grunk
Modérateur
Envoyé par Gaulouis
Bonjour à tous,

Avant:

Code php :

@$result=$foo->findBar()->getCoca()->pay();

Aujourd'hui:

Code php :

$result=$foo?->findBar()?->getCoca()?->pay();
L'utilisation de "@" n'a jamais été recommandé , elle ne fait que masquer une erreur , pas la traiter correctement.
le 30/11/2021 à 17:28
Beezar
Membre à l'essai

Il s'agit ici de simplifier la gestion des retours null.
Si tu as besoin d'une gestion fine, tu ne passeras pas par ce système.
Si une exception est levée c'est à toi de l'attraper.

Bref ca ne change rien à la gestion des exceptions.

le 01/12/2021 à 9:00

grunk

Modérateur

Envoyé par Gaulouis

Excellent, tu va peut-être m'apprendre un truc.

En quoi cette nouvelle syntaxe est recommandé ?

Code PHP :

$result=$foo?->findBar()?->getCoca()?->pay();

Comment va-t-elle traiter l'erreur "CoronaException : No such bar open." ou "ExtraException: No coca available."

Comment ça se concrétise le "démasquage" d'erreur ?

La syntaxe que tu évoques (opérateur nullsafe) permet juste d'éviter de vérifier l'état null et d'écrire des trucs comme :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
if(is_null($foo)) { 
	$result = null; 
} else { 
	$bar = $foo->findBar(); 
	if(is_null($bar)) { 
		$result = null; 
	} else { 
		$coca = $bar->getCoca(); 
		if(is_null($coca)) { 
			$result = null; 
		} else { 
			$result = $coca->pay(); 
		} 
	} 
}

Si tu as des problématique d'exception , alors il faut les traiter avec un try/catch et certainement pas avec un "@". Ca c'est vrai depuis php 4.

Code :

1
2
3
4
5
try { 
	$result = $result=$foo?->findBar()?->getCoca()?->pay(); 
} catch(Exception $e) { 
	$result = null; 
}

le 01/12/2021 à 9:35

grunk
Modérateur

Etrange cette utilisation du case sur la syntaxe des énums

le 01/02/2021 à 11:43
Séb.
Expert éminent

Bizarre aussi d'accepter le 0O en plus du 0o pour débuter la notation octale. Quelqu'un ne connaissant pas la subtilité peut y perdre des heures s'il ne remarque pas le O.

le 01/02/2021 à 15:04

TotoParis

Membre expérimenté

Envoyé par grunk

Etrange cette utilisation du case sur la syntaxe des énums

En effet.
En Pascal, les énumérations existent depuis le début !
Exemple :

Code Pascal :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
type 
  TFruits = (Orange, Pomme, Banane, Peche, Pasteque, Pamplemousse); 
type 
  TCorbeilleDeFruits = set of TFruits; 
  
  
var 
  fruit: TFruits; 
begin 
  for fruit := low(TFruits) to high(TFruits) do 
  begin 
    ShowMessage(GetEnumName(typeinfo(TFruits), ord(fruit))); 
  end; 
end;

le 01/02/2021 à 21:31

Gaulouis
Membre confirmé

Ok, merci à vous deux, je viens de comprendre.

Il s'agit ici de simplifier la gestion des retours null.

@ le faisait déjà sur les propriétés mais pas sur les méthodes.
Et pour une raison de rétrocompatibilité le choix a été d'ajouter des élément de langage plutôt que de modifier le comportement historique.

le 01/12/2021 à 18:24
Séb.
Expert éminent

@ le faisait déjà sur les propriétés mais pas sur les méthodes.

Non, @ ne fait que cacher l'erreur et ne change rien à la valeur retournée.
@ est principalement est utile sur les fonctions d'ouverture de flux difficilement prévisibles et qui émettent un warning, comme fopen(),
autrement il vaut mieux l'éviter.

le 01/12/2021 à 20:43

Gaulouis

Membre confirmé

Envoyé par PHP Manual >

PHP supports one error control operator: the at sign (@). When prepended to an expression in PHP, any diagnostic error that might be generated by that expression will be suppressed.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php

class A {
  function findBar() {
    return $this;
  }
  function getCoca() {
    return null;//throw new Exception("is not catchable by '@' or '?'");
  }
  function pay() {
    return 2.50;
  }
}

$foo = new A;

Code :

<?php $result = $foo->usualBar->cocaDrink->price;//Warning: Attempt to read property "cocaDrink" on null

Code :

<?php $result = $foo?->findBar()?->getCoca()->pay();//Fatal error: Call to a member function pay() on null

Passons les erreurs sous silence:

Code :

1
2
<?php @$result = $foo->usualBar->cocaDrink->price;
var_dump($result);// output null

Code :

1
2
<?php $result = $foo?->findBar()?->getCoca()?->pay();
var_dump($result);// output null

J'aurai préféré :

Code :

1
2
<?php @$result = $foo->usualBar()->cocaDrink()->price();// mute (Fatal error: Call to undefined method A::usualBar )
var_dump($result);// output null

Donc les '?' permetent de passer sous silence des erreur "Uncaught Error" mais pas "@" ... Pourquoi ?

le 01/12/2021 à 22:12

Séb.
Expert éminent

Envoyé par Gaulouis

Donc les '?' permetent de passer sous silence des erreur "Uncaught Error" mais pas "@" ... Pourquoi ?

Il s'agit d'une exception, et pas d'une erreur ("Uncaught". @ ne s'occupe que des erreurs. Pour les exceptions il y a try/catch/finally

le 02/12/2021 à 14:48

Poster une réponse