PHP 7.4, la prochaine version mineure de PHP 7, est sortie depuis le 28 novembre 2019. Il est donc temps pour nous de nous plonger dans certains des ajouts les plus excitants et de nouvelles fonctionnalit\u00e9s qui ont rendu\u00a0PHP plus rapide et plus fiable.<\/p>\n
Mise \u00e0 jour :<\/strong> PHP 8.1 (version officielle)<\/a> est maintenant disponible pour tous les clients de Kinsta. PHP 7.4 n’est plus support\u00e9 chez Kinsta. Veuillez noter que nous prenons en charge les versions de PHP 7.4, 8.0, 8.1, 8.2, 8.3, 8.4 et 8.5.<\/p>\n M\u00eame si PHP 7.4 am\u00e9liore consid\u00e9rablement les performances et la lisibilit\u00e9 du code, PHP 8<\/a> sera le v\u00e9ritable jalon pour les performances de PHP, puisque la proposition pour l’inclusion du JIT<\/a> a d\u00e9j\u00e0 \u00e9t\u00e9 approuv\u00e9e.<\/p>\n Quoi qu’il en soit, aujourd’hui, nous passons en revue quelques-unes des fonctionnalit\u00e9s les plus int\u00e9ressantes et des changements que nous attendons avec PHP 7.4. Juste pour information, voici les dates importantes de la version 7.4 :<\/p>\n Vous pouvez consulter la liste compl\u00e8te des fonctionnalit\u00e9s et des ajouts sur la page officielle du RFC<\/a>.<\/p>\n Dans cet article, nous couvrons plusieurs changements et fonctionnalit\u00e9s qui devraient \u00eatre ajout\u00e9s au langage avec la version finale de PHP 7.4 :<\/p>\n Disponible depuis PHP 5.6, le unpacking d’arguments<\/a> est une syntaxe pour le d\u00e9ballage des arrays et des Traversables<\/a> en listes d’arguments. Pour d\u00e9compresser un array ou un Traversable, il doit \u00eatre pr\u00e9c\u00e9d\u00e9 de … (3 points), comme montr\u00e9 dans l’exemple suivant :<\/p>\n Maintenant cette RFC PHP 7.4<\/a> propose d’\u00e9tendre cette fonctionnalit\u00e9 aux d\u00e9finitions de array :<\/p>\n Le premier avantage d\u00e9clar\u00e9 de Spread Operator dans l’expression d’un array<\/strong> est la performance. En fait, le doc du RFC dit<\/a> :<\/p>\n L’op\u00e9rateur Spread devrait avoir de meilleures performances que Un avantage significatif de l’op\u00e9rateur Spread est qu’il supporte tous les objets traversables, alors que la fonction Voici un exemple de unpacking d’argument dans l’expression d’un array :<\/p>\n Si vous ex\u00e9cutez ce code avec PHP 7.3 ou une version ant\u00e9rieure, PHP affiche une Parse Error :<\/p>\n Au lieu de cela, PHP 7.4 retournerait un tableau :<\/p>\n Le RFC indique que nous pouvons \u00e9tendre le m\u00eame tableau plusieurs fois. De plus, nous pouvons utiliser la syntaxe de l\u2019op\u00e9rateur Spread partout dans le tableau, car des \u00e9l\u00e9ments normaux peuvent \u00eatre ajout\u00e9s avant ou apr\u00e8s l’op\u00e9rateur Spread. Le code suivant fonctionnera donc comme on peut s’y attendre :<\/p>\n Il est \u00e9galement possible de d\u00e9compresser les tableaux retourn\u00e9s par une fonction directement dans un nouveau tableau :<\/p>\n PHP 7.4 produit le tableau suivant :<\/p>\n Nous pouvons aussi utiliser la syntaxe G\u00e9n\u00e9rator<\/a>:<\/p>\n Mais nous ne sommes pas autoris\u00e9s \u00e0 d\u00e9compresser les tableaux pass\u00e9s par r\u00e9f\u00e9rence. Prenons l’exemple suivant :<\/p>\n Si nous essayons de d\u00e9compresser un tableau par r\u00e9f\u00e9rence, PHP affiche la Parse Error suivante :<\/p>\n Quoi qu’il en soit, si les \u00e9l\u00e9ments du premier tableau sont stock\u00e9s par r\u00e9f\u00e9rence, ils sont \u00e9galement stock\u00e9s par r\u00e9f\u00e9rence dans le second tableau. En voici un exemple :<\/p>\n Et voici ce que nous obtenons avec PHP 7.4 :<\/p>\n La proposition de l’op\u00e9rateur Spread a \u00e9t\u00e9 adopt\u00e9e avec 43 voix contre une.<\/p>\n En PHP, les fonctions anonymes sont<\/a> consid\u00e9r\u00e9es comme assez verbeuses et difficiles \u00e0 impl\u00e9menter et \u00e0 maintenir. Ce RFC<\/a> propose l’introduction de la syntaxe plus courte et plus claire des fonctions arrow<\/strong> (ou short closures), qui devrait nous permettre de nettoyer de mani\u00e8re significative notre code PHP.<\/p>\n Consider the following example:<\/p>\n PHP 7.4 permet d’utiliser une syntaxe plus concise, et la fonction ci-dessus pourrait \u00eatre r\u00e9\u00e9crite comme suit :<\/p>\n Actuellement, les, fonctions anonymes<\/a> (fermetures) peuvent h\u00e9riter des variables d\u00e9finies dans le scope parent gr\u00e2ce \u00e0 la construction du langage Mais avec PHP 7.4, les variables d\u00e9finies dans le scope parent sont implicitement captur\u00e9es par valeur<\/strong> (liaison implicite par valeur au scope). On peut donc \u00e9crire l’ensemble de la fonction vue ci-dessus sur une seule ligne :<\/p>\n La variable d\u00e9finie dans le scope parent peut \u00eatre utilis\u00e9e dans la fonction arrow exactement comme si nous utilisions La nouvelle syntaxe est une grande am\u00e9lioration au langage car elle nous permet de construire un code plus lisible et maintenable. On peut aussi utiliser des use types de param\u00e8tres et de retour<\/a>, des valeurs par d\u00e9faut, des listes d’arguments de longueur variable (fonctions variadiques<\/a>), on peut passer et retourner par r\u00e9f\u00e9rence, etc. Enfin, les fermetures courtes peuvent \u00e9galement \u00eatre utilis\u00e9es dans les m\u00e9thodes de classe, et elles peuvent utiliser la variable\u00a0et elles peuvent utiliser la variable Cette RFC a \u00e9t\u00e9 approuv\u00e9e par 51 \u00e0 8 voix, nous pouvons donc nous attendre \u00e0 ce qu’elle fasse partie des ajouts PHP 7.4.<\/p>\n Ajout\u00e9 avec PHP 7, l’op\u00e9rateur coalesce<\/a> ( Ce que fait ce code est assez simple : il r\u00e9cup\u00e8re le param\u00e8tre requ\u00eate et d\u00e9finit une valeur par d\u00e9faut s’il n’existe pas<\/strong>. La signification de cette ligne est claire, mais que se passerait-il si nous avions des noms de variables beaucoup plus longs comme dans cet exemple du RFC ?<\/p>\n \u00c0 long terme, ce code pourrait \u00eatre un peu difficile \u00e0 maintenir. Ainsi, dans le but d’aider les d\u00e9veloppeurs \u00e0 \u00e9crire un code plus intuitif, cette RFC<\/a> propose l’introduction de l’op\u00e9rateur d’affectation coalesce null<\/strong> Si la valeur du param\u00e8tre de gauche est Cette proposition a \u00e9t\u00e9 approuv\u00e9e par 37 voix contre 4.<\/p>\n Les d\u00e9clarations de type d’argument, ou indices de type, permettent de sp\u00e9cifier le type d’une variable qui doit \u00eatre transmise \u00e0 une fonction ou \u00e0 une m\u00e9thode de classe. Les indices de type sont une fonctionnalit\u00e9 disponible depuis PHP 5, et depuis PHP 7.2<\/a> nous pouvons les utiliser avec le type de donn\u00e9es Tous les types sont support\u00e9s, \u00e0 l’exception de Le RFC explique la raison pour laquelle Le type void n’est pas support\u00e9, car il n’est pas utile et sa s\u00e9mantique n’est pas claire.<\/p><\/blockquote>\n Le type callable n’est pas support\u00e9, car son comportement d\u00e9pend du contexte.<\/p><\/blockquote>\n Ainsi, nous pouvons utiliser en toute s\u00e9curit\u00e9 Les types peuvent \u00eatre utilis\u00e9s sur des propri\u00e9t\u00e9s statiques :<\/p>\n Ils sont \u00e9galement autoris\u00e9s avec la notation Il est possible de d\u00e9finir des valeurs de propri\u00e9t\u00e9s par d\u00e9faut, qui doivent bien s\u00fbr correspondre au type de propri\u00e9t\u00e9 d\u00e9clar\u00e9, mais seules les propri\u00e9t\u00e9s nullables peuvent avoir une valeur Le m\u00eame type s’applique \u00e0 toutes les propri\u00e9t\u00e9s d’une m\u00eame d\u00e9claration :<\/p>\n Que se passe-t-il si nous faisons une erreur sur le type de propri\u00e9t\u00e9 ? Consid\u00e9rez le code suivant :<\/p>\n Dans le code ci-dessus, nous avons d\u00e9clar\u00e9 un type de propri\u00e9t\u00e9 string, mais nous avons d\u00e9fini un tableau comme valeur de propri\u00e9t\u00e9. Dans un tel sc\u00e9nario, nous obtenons l’erreur fatale suivante :<\/p>\n Ce RFC a \u00e9t\u00e9 approuv\u00e9 par 70 voix contre une.<\/p>\n\n Avec cette RFC<\/a>, PHP 7.4 introduit la classe WeakReference<\/a>, qui permet aux programmeurs de conserver une r\u00e9f\u00e9rence \u00e0 un objet qui n’emp\u00eache pas que l’objet lui-m\u00eame soit d\u00e9truit.<\/p>\n Actuellement PHP supporte les r\u00e9f\u00e9rences faibles en utilisant une extension comme pecl-weakref. Quoi qu’il en soit, la nouvelle API est diff\u00e9rente de la classe Voici un exemple de l’auteur<\/a> de cette proposition, Nikita Popov :<\/p>\n Le premier Slides for my PHP 7.4 talk at #PHPRussia2019<\/a>. Was a great conference!https:\/\/t.co\/zLr9Bj2aKl<\/a><\/p>\n — Nikita Popov (@nikita_ppv) May 19, 2019<\/a><\/p><\/blockquote>\n\n
Quoi de neuf dans PHP avec PHP 7.4 ?<\/h2>\n
Oubliez array_merge : PHP 7.4 Apporte l’op\u00e9rateur Spread dans l’expression de Array<\/h3>\n
function test(...$args) { var_dump($args); }\ntest(1, 2, 3);<\/code><\/pre>\n$arr = [...$args];<\/code><\/pre>\narray_merge<\/code>. Ce n’est pas seulement parce que l’op\u00e9rateur spread est une structure de langage tandis que array_merge<\/code> iest une fonction, mais aussi parce que l’optimisation du temps de compilation peut \u00eatre performante pour des arrays constants.<\/p><\/blockquote>\narray_merge<\/code> ne supporte que les arrays.<\/p>\n$parts = ['apple', 'pear'];\n$fruits = ['banana', 'orange', ...$parts, 'watermelon'];\nvar_dump($fruits);<\/code><\/pre>\nParse error: syntax error, unexpected '...' (T_ELLIPSIS), expecting ']' in \/app\/spread-operator.php on line 3<\/code><\/pre>\narray(5) {\n\t[0]=>\n\tstring(6) \"banana\"\n\t[1]=>\n\tstring(6) \"orange\"\n\t[2]=>\n\tstring(5) \"apple\"\n\t[3]=>\n\tstring(4) \"pear\"\n\t[4]=>\n\tstring(10) \"watermelon\"\n}<\/code><\/pre>\n$arr1 = [1, 2, 3];\n$arr2 = [4, 5, 6];\n$arr3 = [...$arr1, ...$arr2];\n$arr4 = [...$arr1, ...$arr3, 7, 8, 9];<\/code><\/pre>\nfunction buildArray(){\n\treturn ['red', 'green', 'blue'];\n}\n$arr1 = [...buildArray(), 'pink', 'violet', 'yellow'];<\/code><\/pre>\narray(6) {\n\t[0]=>\n\tstring(3) \"red\"\n\t[1]=>\n\tstring(5) \"green\"\n\t[2]=>\n\tstring(4) \"blue\"\n\t[3]=>\n\tstring(4) \"pink\"\n\t[4]=>\n\tstring(6) \"violet\"\n\t[5]=>\n\tstring(6) \"yellow\"\n}<\/code><\/pre>\nfunction generator() {\n\tfor ($i = 3; $i <= 5; $i++) {\n\t\tyield $i;\n\t}\n}\n$arr1 = [0, 1, 2, ...generator()];<\/code><\/pre>\n$arr1 = ['red', 'green', 'blue'];\n$arr2 = [...&$arr1];<\/code><\/pre>\nParse error: syntax error, unexpected '&' in \/app\/spread-operator.php on line 3<\/code><\/pre>\n$arr0 = 'red';\n$arr1 = [&$arr0, 'green', 'blue'];\n$arr2 = ['white', ...$arr1, 'black'];<\/code><\/pre>\narray(5) {\n\t[0]=>\n\tstring(5) \"white\"\n\t[1]=>\n\t&string(3) \"red\"<\/strong>\n\t[2]=>\n\tstring(5) \"green\"\n\t[3]=>\n\tstring(4) \"blue\"\n\t[4]=>\n\tstring(5) \"black\"\n}<\/code><\/pre>\nFonctions Arrow 2.0 (Short Closures)<\/h3>\n
function cube($n){\n\treturn ($n * $n * $n);\n}\n$a = [1, 2, 3, 4, 5];\n$b = array_map('cube', $a);\nprint_r($b);<\/code><\/pre>\n$a = [1, 2, 3, 4, 5];\n$b = array_map(fn($n) => $n * $n * $n, $a);\nprint_r($b);<\/code><\/pre>\nuse<\/code> comme indiqu\u00e9 ci-dessous :<\/p>\n$factor = 10;\n$calc = function($num) use($factor){\n\treturn $num * $factor;\n};<\/code><\/pre>\n$factor = 10;\n$calc = fn($num) => $num * $factor;<\/code><\/pre>\nuse($var)<\/code>, et il n’est pas possible de modifier une variable du scope parent.<\/p>\n$this<\/code> tout comme une closure r\u00e9guli\u00e8re.<\/p>\nOp\u00e9rateur d’assignation Coalesce Null<\/h3>\n
??<\/code>) est pratique lorsque nous avons besoin d’utiliser un op\u00e9rateur ternaire en conjonction avec isset()<\/code>. Cela retourne le premier op\u00e9rande s’il existe et n’est pas NULL<\/code>. Sinon, elle retourne le deuxi\u00e8me op\u00e9rande. En voici un exemple :<\/p>\n$username = $_GET['user'] ?? 'nobody';<\/code><\/pre>\n$this->request->data['comments']['user_id'] = $this->request->data['comments']['user_id'] ?? 'value';<\/code><\/pre>\n(??=). Ainsi, au lieu d'\u00e9crire le code pr\u00e9c\u00e9dent, nous pourrions \u00e9crire ce qui suit :<\/code><\/p>\n$this->request->data['comments']['user_id'] ??= 'value';<\/code><\/pre>\nnull<\/code>, la valeur du param\u00e8tre de droite est utilis\u00e9e.
\nNotez que, bien que l’op\u00e9rateur coalesce soit un op\u00e9rateur de comparaison, ??=<\/code> est un op\u00e9rateur d’assignation.<\/p>\nPropri\u00e9t\u00e9s Typed 2.0<\/h3>\n
object<\/code>. Maintenant PHP 7.4 apporte une allusion de type un pas en avant en ajoutant le support pour les d\u00e9clarations de type de propri\u00e9t\u00e9 de premi\u00e8re classe<\/a>. En voici un exemple tr\u00e8s simple :<\/p>\nclass User {\n\tpublic int $id;\n\tpublic string $name;\n}<\/code><\/pre>\nvoid<\/code> et callable<\/code>:<\/p>\npublic int $scalarType;\nprotected ClassName $classType;\nprivate ?ClassName $nullableClassType;<\/code><\/pre>\nvoid<\/code> et callable<\/code> ne sont pas support\u00e9s :<\/p>\nbool<\/code>, int<\/code>, float<\/code>, string<\/code>, array<\/code>, object<\/code>, iterable<\/code>, self<\/code>, parent<\/code>, tout nom de classe ou d’interface, et les types nullables<\/a>\u00a0(?type<\/code>).<\/p>\npublic static iterable $staticProp;<\/code><\/pre>\nvar<\/code>:<\/p>\nvar bool $flag;<\/code><\/pre>\nnull<\/code> par d\u00e9faut:<\/p>\npublic string $str = \"foo\";\npublic ?string $nullableStr = null;<\/code><\/pre>\npublic float $x, $y;<\/code><\/pre>\nclass User {\n\tpublic int $id;\n\tpublic string $name;\n}\n\n$user = new User;\n$user->id = 10;\n$user->name = [];<\/code><\/pre>\nFatal error: Uncaught TypeError: Typed property User::$name must be string, array used in \/app\/types.php:9<\/code><\/pre>\nWeak References<\/h3>\n
WeakRef<\/code> document\u00e9e.<\/p>\n$object = new stdClass;\n$weakRef = WeakReference::create($object);\n\nvar_dump($weakRef->get());\nunset($object);\nvar_dump($weakRef->get());<\/code><\/pre>\nvar_dump<\/code> imprime object(stdClass)#1 (0) {}<\/code>, tandis que le second var_dump<\/code> prints NULL<\/code>, car l’objet r\u00e9f\u00e9renc\u00e9 a \u00e9t\u00e9 d\u00e9truit.<\/p>\n\n