Ce este nou în PHP 8.2 — Caracteristici noi, deprecieri, modificări și multe altele

PHP 8.2 se bazează pe baza reînnoită prezentată de PHP 8.0 și PHP 8.1. Lansarea este planificată pe 24 noiembrie 2022.

Acest articol va acoperi în detaliu noutățile PHP 8.2 - de la noile sale funcții și îmbunătățiri până la deprecieri și modificări minore, le vom analiza pe toate.

Deoarece PHP 8.2 a intrat în înghețarea funcțiilor pe 19 iulie 2022, nu vă puteți aștepta la nicio adăugare semnificativă la această listă.

Excitat? Suntem și noi.

Sa incepem!

Caracteristici noi și îmbunătățiri în PHP 8.2

Să începem prin a explora toate cele mai recente funcții PHP 8.2. Este o listă destul de extinsă:

Cursuri noi readonly

PHP 8.1 a introdus caracteristica numai pentru readonly pentru proprietățile clasei. Acum, PHP 8.2 adaugă suport pentru a declara întreaga clasă ca fiind doar în readonly .

Dacă declarați o clasă ca fiind numai în readonly , toate proprietățile sale vor moșteni automat caracteristica numai în readonly . Astfel, declararea unei clase readonly este la fel cu declararea fiecărei proprietăți de clasă ca readonly .

De exemplu, cu PHP 8.1, a trebuit să scrieți acest cod plictisitor pentru a declara toate proprietățile clasei ca fiind doar în readonly :

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

Imaginați-vă același lucru cu multe mai multe proprietăți. Acum, cu PHP 8.2, puteți scrie doar asta:

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

De asemenea, puteți declara clasele abstracte sau finale ca fiind numai în readonly . Aici, ordinea cuvintelor cheie nu contează.

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

De asemenea, puteți declara o clasă numai în readonly fără proprietăți. În mod efectiv, acest lucru previne proprietățile dinamice, permițând în același timp claselor copil să-și declare în mod explicit proprietățile numai de readonly .

În continuare, clasele numai în readonly pot conține numai proprietăți tipizate - aceeași regulă pentru declararea proprietăților individuale numai în citire .

Puteți utiliza proprietatea tip mixed dacă nu puteți declara o proprietate strict tipizată.

Încercarea de a declara o clasă numai în readonly fără o proprietate tipată va avea ca rezultat o eroare fatală:

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

În plus, nu puteți declara doar readonly pentru anumite caracteristici PHP:

• Enumări (deoarece nu pot conține nicio proprietate)
• Trăsături
• Interfețe

Încercarea de a declara oricare dintre aceste caracteristici ca fiind doar în readonly va avea ca rezultat o eroare de analiză.

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

Așa cum este cazul tuturor cuvintelor cheie PHP, cuvântul cheie numai în readonly nu face distincție între majuscule și minuscule.

PHP 8.2 depreciază și proprietățile dinamice (mai multe despre asta mai târziu). Dar nu puteți împiedica adăugarea proprietăților dinamice la o clasă. Cu toate acestea, făcând acest lucru pentru o clasă numai în readonly va avea ca rezultat doar o eroare fatală.

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

Permite true , false și null ca tipuri autonome

PHP include deja tipuri scalare precum int , string și bool . Acesta a fost extins în PHP 8.0 cu adăugarea de tipuri de uniuni, permițând valorilor să fie de diferite tipuri. Același RFC permitea, de asemenea, utilizarea false și null ca parte a unui tip de uniune - totuși, nu erau permise ca tipuri independente.

Dacă ați încercat să declarați false sau null sau ca tipuri de sine stătătoare – fără ca acestea să facă parte dintr-un tip de uniune – a rezultat o eroare fatală.

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

Pentru a evita acest scenariu, PHP 8.2 adaugă suport pentru utilizarea false și null ca tipuri de sine stătătoare. Cu această adăugare, sistemul de tip PHP este mai expresiv și mai complet. Acum puteți declara cu precizie returnarea, parametrul și tipurile de proprietate.

De asemenea, PHP încă nu include un tip true , care pare a fi o contrapartidă naturală a tipului false . PHP 8.2 remediază acest lucru și adaugă suport și pentru tipul true . Nu permite constrângerea, exact așa cum se comportă tipul false .

Atât tipurile true cât și false sunt în esență un tip de uniune de tip bool al PHP. Pentru a evita redundanța, nu puteți declara aceste trei tipuri împreună într-un tip de uniune. Acest lucru va avea ca rezultat o eroare fatală la compilare.

Tipuri de formă normală disjunctivă (DNF).

Forma normală disjunctivă (DNF) este o modalitate standardizată de organizare a expresiilor booleene. Constă într-o disjuncție de conjuncții - în termeni booleeni, acesta este un SAU al AND-urilor .

Aplicarea DNF la declarațiile de tip permite o modalitate standard de a scrie tipuri combinate Union și Intersection pe care analizatorul le poate gestiona. Noua caracteristică de tipuri DNF a PHP 8.2 este simplă, dar puternică dacă este utilizată corespunzător.

RFC oferă următorul exemplu. Se presupune că următoarele interfețe și definiții de clasă există deja:

 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 {}

Cu tipurile DNF, puteți efectua declarații de tip pentru proprietăți, parametri și valori returnate astfel:

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

În unele cazuri, este posibil ca proprietățile să nu fie în forme DNF. Declararea lor ca atare va duce la o eroare de analiză. Dar le puteți rescrie oricând ca:

 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

Trebuie să rețineți că fiecare segment al unui tip DNF trebuie să fie unic. De exemplu, declararea (A&B)|(B&A) este invalidă deoarece cele două segmente OR ed sunt logic aceleași.

În plus, segmentele care sunt subseturi stricte ale celuilalt segment nu sunt permise. Asta pentru că supersetul va avea deja toate instanțele subsetului, ceea ce face redundantă utilizarea DNF.

Redactați parametrii sensibili în Back Traces

Ca aproape orice limbaj de programare, PHP permite urmărirea stivei de apeluri în orice moment al execuției codului. Urmărirea stivei facilitează depanarea codului pentru a remedia erorile și blocajele de performanță. Acesta formează coloana vertebrală a unor instrumente precum Kinsta APM, instrumentul nostru de monitorizare a performanței conceput la comandă pentru site-urile WordPress.

Efectuarea unei urmăriri a stivei nu oprește execuția programului. În mod obișnuit, cele mai multe urme ale stivei rulează în fundal și sunt înregistrate silențios - pentru inspecție ulterioară, dacă este necesar.

Cu toate acestea, unele dintre aceste urme detaliate ale stivei PHP pot fi un dezavantaj dacă le partajați cu servicii terțe - de obicei pentru analiza jurnalului de erori, urmărirea erorilor etc. Aceste urme de stivă pot include informații sensibile, cum ar fi nume de utilizator, parole și variabile de mediu. .

Această propunere RFC oferă un astfel de exemplu:

Un „infractor” obișnuit este PDO care ia parola bazei de date ca parametru de constructor și încearcă imediat să se conecteze la baza de date în cadrul constructorului, în loc să aibă un constructor pur și o metodă separată ->connect() . Astfel, atunci când conexiunea la baza de date eșuează, urmărirea stivei va include parola bazei de date:

 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 vă permite să marcați astfel de parametri sensibili cu un nou atribut \SensitiveParameter . Orice parametru marcat ca fiind sensibil nu va fi listat în urmatoarele dvs. Astfel, le puteți partaja fără probleme cu orice servicii terțe.

Iată un exemplu simplu cu un singur parametru sensibil:

 <?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 */

Când generați un backtrace, orice parametru cu atributul \SensitiveParameter va fi înlocuit cu un obiect \SensitiveParameterValue , iar valoarea sa reală nu va fi niciodată stocată în urmărire. Obiectul SensitiveParameterValue încapsulează valoarea reală a parametrului - dacă aveți nevoie de ea din orice motiv.

Noua funcție mysqli_execute_query și metoda mysqli::execute_query

Ați folosit vreodată funcția mysqli_query() cu valori de utilizator care scapă periculos doar pentru a rula o interogare MySQLi parametrizată?

PHP 8.2 facilitează rularea interogărilor MySQLi parametrizate cu noua mysqli_execute_query($sql, $params) și metoda mysqli::execute_query .

În esență, această nouă funcție este o combinație de mysqli_prepare() , mysqli_execute() și mysqli_stmt_get_result() . Cu acesta, interogarea MySQLi va fi pregătită, legată (dacă treceți vreun parametru) și executată în cadrul funcției în sine. Dacă interogarea rulează cu succes, va returna un obiect mysqli_result . Dacă nu reușește, va returna false .

Propunerea RFC oferă un exemplu simplu, dar puternic:

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

Preluați proprietăți enum în expresii const

Acest RFC propune să se permită operatorului ->/?-> să preia proprietăți enum în expresiile const .

Motivul principal pentru această nouă caracteristică este că nu puteți utiliza obiecte enum în unele locuri, cum ar fi cheile matrice. Într-un astfel de caz, va trebui să repetați valoarea enum doar pentru a o folosi.

Permiterea preluării proprietăților enum în locuri în care obiectele enum nu sunt permise poate simplifica această procedură.

Înseamnă că următorul cod este acum valabil:

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

Și doar pentru a fi în siguranță, acest RFC include și suport pentru operatorul nullsafe ?-> .

Permite constante în trăsături

PHP include o modalitate de reutilizare a codului numită Trăsături. Sunt grozave pentru reutilizarea codului între clase.

În prezent, Trăsăturile permit doar definirea de metode și proprietăți, dar nu și constante. Asta înseamnă că nu poți defini invarianții așteptați de o trăsătură în cadrul trăsăturii în sine. Pentru a ocoli această limitare, trebuie să definiți constante în clasa sa de compunere sau o interfață implementată de clasa sa de compunere.

Acest RFC propune să permită definirea constantelor în Trăsături. Aceste constante pot fi definite la fel cum ați defini constantele de clasă. Acest exemplu luat direct din RFC eliberează aerul din jurul utilizării sale:

 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'; } } }

Constantele de trăsătură sunt, de asemenea, îmbinate în definiția clasei care compun, la fel ca proprietatea unei trăsături și definițiile metodei. De asemenea, au restricții similare cu proprietățile Trăsăturilor. După cum se menționează în RFC, această propunere – deși un început bun – necesită lucrări suplimentare pentru a consolida caracteristica.

Deprecieri în PHP 8.2

Acum putem trece la explorarea tuturor depreciărilor din PHP 8.2. Această listă nu este la fel de mare ca noile sale caracteristici:

Depreciere proprietăți dinamice (și atribut nou #[AllowDynamicProperties] )

Până la PHP 8.1, puteți seta și recupera în mod dinamic proprietățile de clasă nedeclarate în PHP. De exemplu:

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

Aici, clasa Post nu declară o proprietate de name . Dar deoarece PHP permite proprietăți dinamice, îl puteți seta în afara declarației clasei. Acesta este cel mai mare - și posibil, singurul - avantaj al său.

Proprietățile dinamice permit erori și comportamente neașteptate să apară în codul dvs. De exemplu, dacă faceți vreo greșeală în timp ce declarați o proprietate de clasă în afara clasei, este ușor să pierdeți urma - mai ales când depanați orice erori din acea clasă.

Începând cu PHP 8.2, proprietățile dinamice sunt depreciate. Setarea unei valori pentru o proprietate de clasă nedeclarată va emite o notificare de depreciere prima dată când proprietatea este setată.

 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;

Cu toate acestea, începând cu PHP 9.0, setarea aceluiași lucru va genera o eroare ErrorException .

Dacă codul dvs. este plin de proprietăți dinamice - și există o mulțime de cod PHP care este - și dacă doriți să opriți aceste notificări de depreciere după actualizarea la PHP 8.2, puteți utiliza noul atribut #[AllowDynamicProperties] al PHP 8.2 pentru a permite dinamica. proprietăți pe clase.

 #[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 RFC, clasele marcate ca #[AllowDynamicProperties] , precum și clasele lor secundare, pot continua să utilizeze proprietăți dinamice fără depreciere sau eliminare.

De asemenea, ar trebui să rețineți că, în PHP 8.2, singura clasă grupată marcată ca #[AllowDynamicProperties] este stdClass . Mai mult decât atât, orice proprietăți accesate prin metodele magice PHP __get() sau __set() nu sunt considerate proprietăți dinamice, astfel încât nu vor arunca o notificare de depreciere.

Renunțați la apelurile parțial acceptate

O altă modificare PHP 8.2, deși cu un impact mai neglijabil, este deprecierea apelabilelor parțial acceptate.

Aceste apelabile sunt denumite parțial acceptate deoarece nu puteți interacționa direct cu ele prin $callable() . Puteți ajunge la ele doar cu funcția call_user_func($callable) . Lista acestor apelabile nu este lungă:

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

Începând cu PHP 8.2, orice încercare de a invoca astfel de apelabile - cum ar fi prin intermediul call_user_func() sau array_map() - va arunca un avertisment de depreciere.

RFC original oferă un raționament solid în spatele acestei deprecieri:

În afară de ultimele două cazuri, toate aceste apelabile sunt dependente de context. Metoda la care se referă "self::method" depinde de clasa din care se efectuează apelul sau verificarea apelabilității. În practică, acest lucru este valabil și pentru ultimele două cazuri, atunci când este utilizat sub forma [new Foo, "parent::method"] .

Reducerea dependenței de context a apelabilelor este scopul secundar al acestui RFC. După acest RFC, singura dependență de domeniu rămasă este vizibilitatea metodei: "Foo::bar" poate fi vizibil într-un domeniu, dar nu în altul. Dacă apelabilele ar fi limitate la metode publice în viitor (în timp ce metodele private ar trebui să utilizeze apelabile de primă clasă sau Closure::fromCallable() pentru a fi independent de domeniul de aplicare), atunci tipul apelabil ar deveni bine definit și ar putea să fie utilizat ca tip de proprietate. Cu toate acestea, modificări la gestionarea vizibilității nu sunt propuse ca parte a acestui RFC .

Conform RFC original, funcția is_callable() și tipul callable vor continua să accepte aceste apelabile ca excepții. Dar numai până când suportul pentru ele este eliminat în întregime de la PHP 9.0 înainte.

Pentru a evita confuzia, acest domeniu de aplicare a notificării de depreciere a fost extins cu un nou RFC - acum include aceste excepții.

Este bine să vezi că PHP se îndreaptă către un tip callable bine definit.

Depreciați #utf8_encode() și utf8_decode() .

Funcțiile încorporate PHP utf8_encode() și utf8_decode() convertesc șirurile codificate în ISO-8859-1 (“Latin 1”) în și de la UTF-8.

Cu toate acestea, numele lor sugerează o utilizare mai generală decât permite implementarea lor. Codificarea „Latin 1” este de obicei confundată cu alte codificări precum „Pagina de cod Windows 1252”.

În plus, veți vedea de obicei Mojibake atunci când aceste funcții nu pot converti corect niciun șir. Lipsa mesajelor de eroare înseamnă, de asemenea, că este dificil să le descoperiți, mai ales într-o mare de text altfel lizibil.

PHP 8.2 depreciază atât #utf8_encode() cât și utf8_decode() . Dacă le invocați, veți vedea aceste notificări de depreciere:

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

RFC sugerează utilizarea extensiilor acceptate de PHP, cum ar fi mbstring , iconv și intl .

Renunțați la interpolarea șirurilor de caractere ${}

PHP permite încorporarea variabilelor în șiruri de caractere cu ghilimele duble ( " ) și heredoc ( <<< ) în mai multe moduri:

1. Încorporarea directă a variabilelor — “$foo”
2. Cu acolade în afara variabilei — “{$foo}”
3. Cu bretele după semnul dolarului – “${foo}”
4. Variabile variabile — “${expr}” — echivalent cu utilizarea (string) ${expr}

Primele două moduri au avantajele și dezavantajele lor, în timp ce ultimele două au o sintaxă complexă și conflictuală. PHP 8.2 depreciază ultimele două moduri de interpolare a șirurilor.

Ar trebui să evitați interpolarea șirurilor în acest fel de acum înainte:

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

Începând cu PHP 9.0, aceste deprecieri vor fi actualizate pentru a genera o eroare de excepție.

Depreciați funcțiile mbstring pentru entitățile Base64/QPrint/Uuencode/HTML

Funcțiile mbstring (șir multi-octeți) ale PHP ne ajută să lucrăm cu Unicode, entități HTML și alte codificări de text vechi.

Cu toate acestea, Base64, Uuencode și QPrint nu sunt codificări text și fac încă parte din aceste funcții - în primul rând din motive moștenite. PHP include, de asemenea, implementări separate ale acestor codificări.

În ceea ce privește entitățile HTML, PHP are funcții încorporate — htmlspecialchars() și htmlentities() — pentru a le gestiona mai bine. De exemplu, spre deosebire de mbstring, aceste funcții vor converti și < . > , și caractere & la entitățile HTML.

În plus, PHP își îmbunătățește întotdeauna funcțiile încorporate - la fel ca PHP 8.1 cu funcții de codificare și decodare HTML.

Deci, ținând cont de toate acestea, PHP 8.2 renunță la utilizarea mbstring pentru aceste codificări (etichetele nu țin cont de majuscule și minuscule):

• BAZĂ64
• UUENCODE
• HTML-ENTITĂȚI
• html (alias de HTML-ENTITIES)
• Citat-Imprimabil
• qprint (alias de Quoted-Printable)

Începând cu PHP 8.2, utilizarea mbstring pentru a codifica/decoda oricare dintre cele de mai sus va emite o notificare de depreciere. PHP 9.0 va elimina complet suportul mbstring pentru aceste codificări.

Alte modificări minore în PHP 8.2

În cele din urmă, putem discuta despre modificările minore ale PHP 8.2, inclusiv despre caracteristicile și funcționalitățile sale eliminate.

Eliminați suportul pentru libmysql din mysqli

Începând de acum, PHP permite atât driverelor mysqli , cât și PDO_mysql să se construiască împotriva bibliotecilor mysqlnd și libmysql . Cu toate acestea, driverul implicit și recomandat începând cu PHP 5.4 a fost mysqlnd .

Ambele drivere au multe avantaje și dezavantaje. Cu toate acestea, eliminarea suportului pentru unul dintre ele - în mod ideal, eliminarea libmysql deoarece nu este implicit - va simplifica codul PHP și testele unitare.

Pentru a face un argument pentru această favoare, RFC enumeră multe avantaje ale mysqlnd :

• Este livrat cu PHP
• Utilizează managementul memoriei PHP pentru a monitoriza utilizarea memoriei și
  îmbunătăți performanța
• Oferă funcții de calitate a vieții (de exemplu get_result() )
• Returnează valori numerice folosind tipuri native PHP
• Funcționalitatea sa nu depinde de biblioteca externă
• Funcționalitate opțională de plugin
• Suportă interogări asincrone

RFC enumeră, de asemenea, câteva avantaje ale libmysql , inclusiv:

• Reconectarea automată este posibilă ( mysqlnd nu acceptă această funcționalitate în mod intenționat, deoarece poate fi exploatată cu ușurință)
• Moduri de autentificare LDAP și SASL ( mysqlnd poate adăuga această caracteristică în curând)

În plus, RFC listează multe dezavantaje ale libmysql - incompatibilitatea cu modelul de memorie PHP, multe teste eșuate, scurgeri de memorie, funcționalități diferite între versiuni etc.

Ținând cont de toate acestea, PHP 8.2 a eliminat suportul pentru construirea mysqli împotriva libmysql .

Dacă doriți să adăugați orice funcționalitate care este disponibilă numai cu libmysql , va trebui să o adăugați în mod explicit la mysqlnd ca cerere de caracteristică. De asemenea, nu puteți adăuga reconectare automată.

Conversie de caz independentă de localitate

Înainte de PHP 8.0, localitatea PHP era moștenită din mediul de sistem. Dar acest lucru ar putea cauza o problemă în unele cazuri marginale.

Setarea limbii dvs. în timpul instalării Linux va seta limba corespunzătoare a interfeței de utilizator pentru comenzile sale încorporate. Cu toate acestea, de asemenea, schimbă în mod neașteptat modul în care funcționează funcționalitatea de gestionare a șirurilor din bibliotecă C.

De exemplu, dacă ați selectat limba „turcă” sau „kazah” atunci când instalați Linux, veți descoperi că apelarea toupper('i') pentru a obține echivalentul său majuscul ar obține capitalul punctat I (U+0130, I ).

PHP 8.0 a oprit această anomalie prin setarea localului implicit la „C”, cu excepția cazului în care utilizatorul o modifică în mod explicit prin setlocale() .

PHP 8.2 merge și mai departe prin eliminarea sensibilității locale din conversiile majuscule și minuscule. Acest RFC modifică în primul rând strtolower() , strtoupper() și funcțiile conexe. Citiți RFC pentru o listă a tuturor funcțiilor afectate.

Ca alternativă, dacă doriți să utilizați conversia localizată a majusculelor, atunci puteți utiliza mb_strtolower() .

Îmbunătățirea extensiei aleatorii

PHP intenționează să-și revizuiască funcționalitatea aleatorie.

Începând de acum, funcționalitatea aleatorie a PHP se bazează în mare măsură pe starea Mersenne Twister. Cu toate acestea, această stare este stocată implicit în zona globală a PHP - nu există nicio modalitate de a o accesa utilizatorul. Adăugarea de funcții de randomizare între etapa inițială de însămânțare și utilizarea intenționată ar rupe codul.

Menținerea unui astfel de cod poate fi și mai complicată atunci când codul dvs. folosește pachete externe.

Astfel, funcționalitatea aleatorie curentă a PHP nu poate reproduce valori aleatoare în mod consecvent. Eșuează chiar și testele statistice empirice ale generatoarelor uniforme de numere aleatoare, cum ar fi Crush și BigCrush de la TestU01. Limitarea pe 32 de biți a lui Mersenne Twister exacerbează și mai mult acest lucru.

Astfel, utilizarea funcțiilor încorporate PHP — shuffle() , str_shuffle() , array_rand() — nu este recomandată dacă aveți nevoie de numere aleatoare securizate criptografic. În astfel de cazuri, va trebui să implementați o nouă funcție folosind random_int() sau funcții similare.

Cu toate acestea, mai multe probleme cu acest RFC au fost ridicate după începerea votării. Acest eșec a forțat echipa PHP să noteze toate problemele într-un RFC separat, cu o opțiune de vot creată pentru fiecare problemă. Ei vor decide să meargă mai departe doar după ce vor ajunge la un consens.

RFC-uri suplimentare în PHP 8.2

PHP 8.2 include, de asemenea, multe funcții noi și modificări minore. Le vom menționa mai jos cu link-uri către resurse suplimentare:

1. Nouă funcție curl_upkeep : PHP 8.2 adaugă această nouă funcție la extensia sa Curl. Apelează funcția curl_easy_upkeep() din libcurl, biblioteca C de bază pe care o folosește extensia PHP Curl.
2. Noua funcție ini_parse_quantity : directivele PHP INI acceptă dimensiuni de date cu un sufix de multiplicare. De exemplu, puteți scrie 25 Megaocteți ca 25M sau 42 Gigaocteți ca doar 42G . Aceste sufixe sunt comune în fișierele PHP INI, dar sunt mai puțin frecvente în altă parte. Această nouă funcție analizează valorile PHP INI și returnează dimensiunea datelor lor în octeți.
3. Noua funcție memory_reset_peak_usage : această funcție resetează utilizarea maximă a memoriei returnată de funcția memory_get_peak_usage . Poate fi util atunci când executați aceeași acțiune de mai multe ori și doriți să înregistrați utilizarea maximă a memoriei pentru fiecare rulare.
4. Suport pentru modificatorul fără captură ( /n ) în funcțiile preg_* : în regex, metacaracterele () indică un grup de captură. Aceasta înseamnă că toate potrivirile pentru expresia din paranteză sunt returnate. PHP 8.2 adaugă un modificator fără captură ( /n ) pentru a opri acest comportament.
5. Faceți ca familia iterator_*() să accepte toate iterabilele: De acum, familia iterator_*() din PHP acceptă numai \Traversables (adică nu sunt permise matrice simple). Limitează inutil și acest RFC rezolvă asta.

rezumat

PHP 8.2 se bazează pe îmbunătățirile masive din PHP 8.0 și PHP 8.1, ceea ce nu este o operație ușoară. Credem că cele mai interesante caracteristici PHP 8.2 sunt noile sale tipuri de sine stătătoare, proprietățile de numai citire și numeroasele îmbunătățiri ale performanței.

Abia așteptăm să comparam PHP 8.2 cu diverse cadre PHP și CMS-uri.

Asigurați-vă că marcați această postare de blog pentru referință viitoare.

Ce caracteristici PHP 8.2 sunt preferate? Care deprecieri sunt cele mai puțin preferate? Vă rugăm să împărtășiți părerile dvs. comunității noastre în comentarii!