Novità di PHP 8.2: nuove funzionalità, deprecazioni, modifiche e altro ancora

PHP 8.2 si basa sulla rinnovata base stabilita da PHP 8.0 e PHP 8.1. L'uscita è prevista per il 24 novembre 2022.

Questo articolo tratterà in dettaglio le novità di PHP 8.2: dalle nuove funzionalità e miglioramenti alle deprecazioni e alle modifiche minori, le esamineremo tutte.

Poiché PHP 8.2 è entrato nel blocco delle funzionalità il 19 luglio 2022, non puoi aspettarti aggiunte significative a questo elenco.

Emozionato? Lo siamo anche noi.

Cominciamo!

Nuove funzionalità e miglioramenti in PHP 8.2

Iniziamo esplorando tutte le ultime funzionalità di PHP 8.2. È un elenco piuttosto ampio:

Nuove classi readonly

PHP 8.1 ha introdotto la funzione di readonly per le proprietà delle classi. Ora, PHP 8.2 sta aggiungendo il supporto per dichiarare l'intera classe come readonly .

Se dichiari una classe come readonly , tutte le sue proprietà erediteranno automaticamente la funzione readonly . Pertanto, dichiarare una classe readonly a dichiarare ogni proprietà di classe come readonly .

Ad esempio, con PHP 8.1, dovevi scrivere questo noioso codice per dichiarare tutte le proprietà della classe come di readonly :

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

Immagina lo stesso con molte più proprietà. Ora, con PHP 8.2, puoi semplicemente scrivere questo:

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

Puoi anche dichiarare classi astratte o finali come di readonly . Qui, l'ordine delle parole chiave non ha importanza.

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

Puoi anche dichiarare una classe di readonly senza proprietà. In effetti, questo impedisce le proprietà dinamiche pur consentendo alle classi figlie di dichiarare esplicitamente le proprie proprietà di readonly .

Successivamente, le classi di readonly possono contenere solo proprietà tipizzate, la stessa regola per dichiarare le singole proprietà di sola lettura .

È possibile utilizzare la proprietà di tipo mixed se non è possibile dichiarare una proprietà tipizzata rigorosamente.

Il tentativo di dichiarare una classe di readonly senza una proprietà tipizzata risulterà in un errore irreversibile:

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

Inoltre, non puoi dichiarare di readonly per alcune funzionalità PHP:

• Enum (poiché non possono contenere alcuna proprietà)
• Tratti
• Interfacce

Il tentativo di dichiarare una di queste funzionalità come di readonly risulterà in un errore di analisi.

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

Come nel caso di tutte le parole chiave PHP, la parola chiave readonly non fa distinzione tra maiuscole e minuscole.

PHP 8.2 depreca anche le proprietà dinamiche (ne parleremo più avanti). Ma non puoi impedire che le proprietà dinamiche vengano aggiunte a una classe. Tuttavia, farlo per una classe di readonly risulterà solo in un errore irreversibile.

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

Consenti true , false e null come tipi autonomi

PHP include già tipi scalari come int , string e bool . Ciò è stato ampliato in PHP 8.0 con l'aggiunta di tipi di unione, consentendo ai valori di essere di tipi diversi. La stessa RFC consentiva anche l'uso di false e null come parte di un tipo di unione, tuttavia non erano consentiti come tipi autonomi.

Se hai provato a dichiarare false o null o come tipi standalone, senza che facessero parte di un tipo di unione, si è verificato un errore irreversibile.

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

Per evitare questo scenario, PHP 8.2 aggiunge il supporto per l'utilizzo di false e null come tipi standalone. Con questa aggiunta, il sistema dei tipi di PHP è più espressivo e completo. È ora possibile dichiarare con precisione i tipi di ritorno, parametro e proprietà.

Inoltre, PHP non include ancora un tipo true , che sembra essere una controparte naturale del tipo false . PHP 8.2 lo risolve e aggiunge anche il supporto per il tipo true . Non consente la coercizione, esattamente come si comporta il tipo false .

Entrambi i tipi true e false sono essenzialmente un tipo di unione del tipo bool di PHP. Per evitare la ridondanza, non è possibile dichiarare questi tre tipi insieme in un tipo di unione. In questo modo si verificherà un errore irreversibile in fase di compilazione.

Tipi di forma normale disgiuntiva (DNF).

La forma normale disgiuntiva (DNF) è un modo standardizzato di organizzare le espressioni booleane. Consiste in una disgiunzione di congiunzioni: in termini booleani, è un OR di AND .

L'applicazione di DNF alle dichiarazioni di tipo consente un modo standard per scrivere tipi di unione e intersezione combinati che il parser può gestire. La nuova funzionalità dei tipi DNF di PHP 8.2 è semplice ma potente se utilizzata correttamente.

La RFC fornisce il seguente esempio. Presuppone che esistano già le seguenti interfacce e definizioni di classe:

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

Con i tipi DNF, puoi eseguire dichiarazioni di tipo per proprietà, parametri e valori restituiti in questo modo:

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

In alcuni casi, le proprietà potrebbero non essere nei moduli DNF. Dichiararli come tali comporterà un errore di analisi. Ma puoi sempre riscriverli come:

 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

Si noti che ogni segmento di un tipo DNF deve essere univoco. Ad esempio, dichiarare (A&B)|(B&A) non è valido poiché i due segmenti OR ed sono logicamente uguali.

In aggiunta a ciò, non sono consentiti nemmeno i segmenti che sono sottoinsiemi rigidi dell'altro segmento. Questo perché il superset avrà già tutte le istanze del sottoinsieme, rendendo ridondante l'uso di DNF.

Redigere i parametri sensibili nelle tracce posteriori

Come quasi tutti i linguaggi di programmazione, PHP consente di tracciare il suo stack di chiamate in qualsiasi momento dell'esecuzione del codice. La traccia dello stack semplifica il debug del codice per correggere errori e colli di bottiglia delle prestazioni. Costituisce la spina dorsale di strumenti come Kinsta APM, il nostro strumento di monitoraggio delle prestazioni progettato su misura per i siti WordPress.

L'esecuzione di una traccia dello stack non interrompe l'esecuzione del programma. In genere, la maggior parte delle tracce dello stack viene eseguita in background e viene registrata in modo invisibile all'utente, per un'ispezione successiva, se necessario.

Tuttavia, alcune di queste tracce dettagliate dello stack PHP possono essere uno svantaggio se le condividi con servizi di terze parti, in genere per l'analisi del registro degli errori, il monitoraggio degli errori, ecc. Queste tracce dello stack possono includere informazioni riservate come nomi utente, password e variabili di ambiente .

Questa proposta RFC fornisce uno di questi esempi:

Un comune "criminale" è PDO che prende la password del database come parametro del costruttore e tenta immediatamente di connettersi al database all'interno del costruttore, invece di avere un costruttore puro e un metodo ->connect() separato . Pertanto, quando la connessione al database fallisce, la traccia dello stack includerà la password del database:

 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 consente di contrassegnare tali parametri sensibili con un nuovo attributo \SensitiveParameter . Qualsiasi parametro contrassegnato come sensibile non verrà elencato nei tuoi backtrace. Pertanto, puoi condividerli senza preoccupazioni con servizi di terze parti.

Ecco un semplice esempio con un singolo parametro sensibile:

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

Quando si genera un backtrace, qualsiasi parametro con l'attributo \SensitiveParameter verrà sostituito con un oggetto \SensitiveParameterValue e il suo valore reale non verrà mai archiviato nella traccia. L'oggetto SensitiveParameterValue incapsula il valore effettivo del parametro, se necessario per qualsiasi motivo.

Nuova funzione mysqli_execute_query e metodo mysqli::execute_query

Hai mai usato la funzione mysqli_query() con valori utente pericolosamente sfuggiti solo per eseguire una query MySQLi parametrizzata?

PHP 8.2 semplifica l'esecuzione di query MySQLi parametrizzate con la nuova mysqli_execute_query($sql, $params) e il metodo mysqli::execute_query .

In sostanza, questa nuova funzione è una combinazione di mysqli_prepare() , mysqli_execute() e mysqli_stmt_get_result() . Con esso, la query MySQLi verrà preparata, vincolata (se si passano parametri) ed eseguita all'interno della funzione stessa. Se la query viene eseguita correttamente, restituirà un oggetto mysqli_result . Se non riesce, restituirà false .

La proposta RFC fornisce un esempio semplice ma potente:

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

Recupera le proprietà enum nelle espressioni const

Questa RFC propone di consentire all'operatore ->/?-> di recuperare le proprietà enum nelle espressioni const .

Il motivo principale di questa nuova funzionalità è che non è possibile utilizzare oggetti enum in alcuni punti, come le chiavi dell'array. In tal caso, dovrai ripetere il valore del caso enum solo per usarlo.

Consentire il recupero delle proprietà enum nei punti in cui gli oggetti enum non sono consentiti può semplificare questa procedura.

Significa che il seguente codice è ora valido:

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

E per sicurezza, questa RFC include anche il supporto per l'operatore nullsafe ?-> .

Consenti costanti nei tratti

PHP include un modo per riutilizzare il codice chiamato Traits. Sono ottimi per il riutilizzo del codice tra le classi.

Attualmente, Traits consente solo di definire metodi e proprietà, ma non costanti. Ciò significa che non puoi definire le invarianti attese da un Trait all'interno del Trait stesso. Per aggirare questa limitazione, è necessario definire costanti nella sua classe di composizione o un'interfaccia implementata dalla sua classe di composizione.

Questa RFC propone di consentire la definizione di costanti in Traits. Queste costanti possono essere definite proprio come definiresti le costanti di classe. Questo esempio tratto direttamente dall'RFC chiarisce l'aria attorno al suo utilizzo:

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

Anche le costanti dei tratti vengono unite nella definizione della classe di composizione, come le definizioni di proprietà e metodi di un tratto. Hanno anche restrizioni simili alle proprietà di Traits. Come notato nella RFC, questa proposta, sebbene sia un buon inizio, necessita di ulteriore lavoro per arricchire la funzione.

Deprecazioni in PHP 8.2

Ora possiamo passare a esplorare tutte le deprecazioni in PHP 8.2. Questo elenco non è così grande come le sue nuove funzionalità:

Deprecate proprietà dinamiche (e nuovo attributo #[AllowDynamicProperties] )

Fino a PHP 8.1, è possibile impostare e recuperare dinamicamente proprietà di classi non dichiarate in PHP. Per esempio:

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

Qui, la classe Post non dichiara una proprietà name . Ma poiché PHP consente proprietà dinamiche, puoi impostarlo al di fuori della dichiarazione di classe. Questo è il suo più grande - e forse l'unico - vantaggio.

Le proprietà dinamiche consentono la comparsa di bug e comportamenti imprevisti nel codice. Ad esempio, se si commette un errore durante la dichiarazione di una proprietà di classe al di fuori della classe, è facile perderne traccia, specialmente durante il debug di eventuali errori all'interno di quella classe.

Da PHP 8.2 in poi, le proprietà dinamiche sono deprecate. L'impostazione di un valore su una proprietà di classe non dichiarata genererà un avviso di deprecazione la prima volta che viene impostata la proprietà.

 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;

Tuttavia, da PHP 9.0 in poi, l'impostazione dello stesso genererà un errore ErrorException .

Se il tuo codice è pieno di proprietà dinamiche, e c'è molto codice PHP che lo è, e se vuoi interrompere questi avvisi di deprecazione dopo l'aggiornamento a PHP 8.2, puoi utilizzare il nuovo attributo #[AllowDynamicProperties] di PHP 8.2 per consentire la dinamica proprietà sulle classi.

 #[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;

Secondo la RFC, le classi contrassegnate come #[AllowDynamicProperties] , così come le classi figlie, possono continuare a usare le proprietà dinamiche senza deprecare o rimuovere.

Dovresti anche notare che, in PHP 8.2, l'unica classe in bundle contrassegnata come #[AllowDynamicProperties] è stdClass . Inoltre, qualsiasi proprietà a cui si accede tramite i metodi magici PHP __get() o __set() non è considerata proprietà dinamica, quindi non genererà un avviso di deprecazione.

Deprecate i callable parzialmente supportati

Un'altra modifica di PHP 8.2, anche se con un impatto più trascurabile, consiste nel deprecare i callable parzialmente supportati.

Questi callable sono definiti parzialmente supportati perché non puoi interagire con loro direttamente tramite $callable() . Puoi raggiungerli solo con la call_user_func($callable) . L'elenco di tali callable non è lungo:

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

Da PHP 8.2 in poi, qualsiasi tentativo di invocare tali callable, ad esempio tramite call_user_func() o array_map() , genererà un avviso di deprecazione.

L'RFC originale fornisce un solido ragionamento alla base di questa deprecazione:

A parte gli ultimi due casi, tutti questi callable dipendono dal contesto. Il metodo a cui fa riferimento "self::method" dipende dalla classe da cui viene eseguita la chiamata o il controllo di callabilità. In pratica, questo di solito vale anche per gli ultimi due casi, quando usato nella forma di [new Foo, "parent::method"] .

Ridurre la dipendenza dal contesto dei callable è l'obiettivo secondario di questa RFC. Dopo questa RFC, l'unica dipendenza dall'ambito ancora rimasta è la visibilità del metodo: "Foo::bar" può essere visibile in un ambito, ma non in un altro. Se i callable dovessero essere limitati ai metodi pubblici in futuro (mentre i metodi privati ​​dovrebbero usare callable di prima classe o Closure::fromCallable() per essere indipendenti dall'ambito), allora il tipo callable diventerebbe ben definito e potrebbe essere utilizzato come tipo di proprietà. Tuttavia, le modifiche alla gestione della visibilità non sono proposte come parte di questa RFC .

Come per l'RFC originale, la funzione is_callable() e il tipo callable continueranno ad accettare questi callable come eccezioni. Ma solo fino a quando il supporto per loro non sarà completamente rimosso da PHP 9.0 in poi.

Per evitare confusione, questo ambito di avviso di ritiro è stato ampliato con una nuova RFC, che ora include queste eccezioni.

È bello vedere che PHP si sta muovendo verso un tipo callable ben definito.

Deprecate #utf8_encode() e utf8_decode()

Le funzioni integrate di PHP utf8_encode() e utf8_decode() convertono le stringhe codificate in ISO-8859-1 ("Latin 1") in e da UTF-8.

Tuttavia, i loro nomi suggeriscono un uso più generale di quello consentito dalla loro implementazione. La codifica "Latin 1" viene comunemente confusa con altre codifiche come la "Pagina codici di Windows 1252".

Inoltre, di solito vedrai Mojibake quando queste funzioni non possono convertire correttamente alcuna stringa. La mancanza di messaggi di errore significa anche che è difficile individuarli, specialmente in un mare di testo altrimenti leggibile.

PHP 8.2 depreca entrambe le #utf8_encode() e utf8_decode() . Se li invochi, vedrai questi avvisi di ritiro:

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

L'RFC suggerisce di utilizzare invece le estensioni supportate da PHP come mbstring , iconv e intl .

Depreca l'interpolazione di stringhe ${}

PHP consente di incorporare variabili in stringhe con virgolette ( " ) e heredoc ( <<< ) in diversi modi:

1. Incorporamento diretto delle variabili — “$foo”
2. Con parentesi graffe al di fuori della variabile — “{$foo}”
3. Con parentesi graffe dopo il simbolo del dollaro — “${foo}”
4. Variabili variabili — “${expr}” — equivalente a using (string) ${expr}

I primi due modi hanno i loro pro e contro, mentre gli ultimi due hanno una sintassi complessa e contrastante. PHP 8.2 depreca gli ultimi due modi di interpolazione delle stringhe.

Dovresti evitare di interpolare stringhe in questo modo andando avanti:

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

A partire da PHP 9.0, queste deprecazioni verranno aggiornate per generare un errore di eccezione.

Deprecate le funzioni mbstring per le entità Base64/QPrint/Uuencode/HTML

Le funzioni mbstring (stringa multibyte) di PHP ci aiutano a lavorare con Unicode, entità HTML e altre codifiche di testo legacy.

Tuttavia, Base64, Uuencode e QPrint non sono codifiche di testo e fanno ancora parte di queste funzioni, principalmente per motivi legacy. PHP include anche implementazioni separate di queste codifiche.

Per quanto riguarda le entità HTML, PHP ha funzioni integrate — htmlspecialchars() e htmlentities() — per gestirle meglio. Ad esempio, a differenza di mbstring, queste funzioni convertiranno anche < . > e & caratteri alle entità HTML.

Inoltre, PHP migliora sempre le sue funzioni integrate, proprio come PHP 8.1 con funzioni di codifica e decodifica HTML.

Quindi, tenendo presente tutto ciò, PHP 8.2 depreca l'uso di mbstring per queste codifiche (le etichette non fanno distinzione tra maiuscole e minuscole):

• BASE64
• UUENCODE
• ENTITÀ HTML
• html (alias di HTML-ENTITÀ)
• Preventivo-stampabile
• qprint (alias di Quoted-Printable)

Da PHP 8.2 in poi, l'utilizzo di mbstring per codificare/decodificare uno qualsiasi dei precedenti emetterà un avviso di deprecazione. PHP 9.0 rimuoverà del tutto il supporto mbstring per queste codifiche.

Altre modifiche minori in PHP 8.2

Infine, possiamo discutere le modifiche minori di PHP 8.2, comprese le sue caratteristiche e funzionalità rimosse.

Rimuovere il supporto per libmysql da mysqli

A partire da ora, PHP consente a entrambi i driver mysqli e PDO_mysql di creare rispetto alle librerie mysqlnd e libmysql . Tuttavia, il driver predefinito e consigliato da PHP 5.4 è mysqlnd .

Entrambi questi driver hanno molti vantaggi e svantaggi. Tuttavia, la rimozione del supporto per uno di essi - idealmente, la rimozione di libmysql poiché non è l'impostazione predefinita - semplificherà il codice PHP e gli unit test.

Per argomentare a favore di questo favore, la RFC elenca molti vantaggi di mysqlnd :

• È in bundle con PHP
• Utilizza la gestione della memoria PHP per monitorare l'utilizzo della memoria e
  migliorare la prestazione
• Fornisce funzioni di qualità della vita (ad es get_result() )
• Restituisce valori numerici utilizzando tipi nativi PHP
• La sua funzionalità non dipende dalla libreria esterna
• Funzionalità plug-in opzionale
• Supporta query asincrone

La RFC elenca anche alcuni vantaggi di libmysql , tra cui:

• È possibile la riconnessione automatica ( mysqlnd non supporta intenzionalmente questa funzionalità perché può essere facilmente sfruttata)
• Modalità di autenticazione LDAP e SASL ( mysqlnd potrebbe aggiungere presto anche questa funzionalità)

Inoltre, la RFC elenca molti svantaggi di libmysql : incompatibilità con il modello di memoria PHP, molti test non riusciti, perdite di memoria, funzionalità diverse tra le versioni, ecc.

Tenendo presente tutto ciò, PHP 8.2 ha rimosso il supporto per la creazione di mysqli contro libmysql .

Se desideri aggiungere funzionalità disponibili solo con libmysql , dovrai aggiungerla esplicitamente a mysqlnd come richiesta di funzionalità. Inoltre, non è possibile aggiungere la riconnessione automatica.

Conversione caso indipendente dalle impostazioni locali

Prima di PHP 8.0, le impostazioni locali di PHP erano ereditate dall'ambiente di sistema. Ma questo potrebbe causare un problema in alcuni casi limite.

L'impostazione della lingua durante l'installazione di Linux imposterà la lingua dell'interfaccia utente appropriata per i suoi comandi integrati. Tuttavia, cambia anche inaspettatamente il modo in cui funziona la funzionalità di gestione delle stringhe della libreria C.

Ad esempio, se hai selezionato la lingua "turco" o "kazako" durante l'installazione di Linux, scoprirai che chiamando toupper('i') per ottenere il suo equivalente maiuscolo otterrai la I maiuscola puntata (U+0130, I ).

PHP 8.0 ha interrotto questa anomalia impostando la locale predefinita su "C", a meno che l'utente non la modifichi esplicitamente tramite setlocale() .

PHP 8.2 va ancora oltre rimuovendo la sensibilità alle impostazioni locali dalle conversioni tra maiuscole e minuscole. Questa RFC cambia principalmente strtolower() , strtoupper() e funzioni correlate. Leggi l'RFC per un elenco di tutte le funzioni interessate.

In alternativa, se desideri utilizzare la conversione dei casi localizzati, puoi utilizzare mb_strtolower() .

Miglioramento dell'estensione casuale

PHP sta pianificando di rivedere la sua funzionalità casuale.

A partire da ora, la funzionalità casuale di PHP si basa fortemente sullo stato di Mersenne Twister. Tuttavia, questo stato è implicitamente memorizzato nell'area globale di PHP: non è possibile che un utente possa accedervi. L'aggiunta di funzioni di randomizzazione tra la fase di seeding iniziale e l'utilizzo previsto interromperebbe il codice.

Il mantenimento di tale codice può essere ancora più complicato quando il codice utilizza pacchetti esterni.

Pertanto, l'attuale funzionalità casuale di PHP non è in grado di riprodurre valori casuali in modo coerente. Fallisce persino i test statistici empirici di generatori di numeri casuali uniformi, come Crush e BigCrush di TestU01. La limitazione a 32 bit di Mersenne Twister lo esacerba ulteriormente.

Pertanto, l'uso delle funzioni integrate di PHP — shuffle() , str_shuffle() , array_rand() — non è raccomandato se hai bisogno di numeri casuali crittograficamente sicuri. In questi casi, dovrai implementare una nuova funzione usando random_int() o funzioni simili.

Tuttavia, diversi problemi con questa RFC sono stati sollevati dopo l'inizio della votazione. Questa battuta d'arresto ha costretto il team PHP a annotare tutti i problemi in una RFC separata, con un'opzione di votazione creata per ogni problema. Decideranno di andare oltre solo dopo aver raggiunto un consenso.

Ulteriori RFC in PHP 8.2

PHP 8.2 include anche molte nuove funzioni e modifiche minori. Li menzioneremo di seguito con collegamenti a risorse aggiuntive:

1. Nuova funzione curl_upkeep : PHP 8.2 aggiunge questa nuova funzione alla sua estensione Curl. Chiama la funzione curl_easy_upkeep() in libcurl, la libreria C sottostante utilizzata dall'estensione PHP Curl.
2. Nuova funzione ini_parse_quantity : le direttive PHP INI accettano dimensioni di dati con un suffisso moltiplicatore. Ad esempio, puoi scrivere 25 Megabyte come 25M o 42 Gigabyte come solo 42G . Questi suffissi sono comuni nei file PHP INI ma non sono comuni altrove. Questa nuova funzione analizza i valori INI di PHP e restituisce la dimensione dei dati in byte.
3. Nuova funzione memory_reset_peak_usage : questa funzione reimposta il picco di utilizzo della memoria restituito dalla funzione memory_get_peak_usage . Può essere utile quando si esegue la stessa azione più volte e si desidera registrare il picco di utilizzo della memoria di ogni corsa.
4. Supporto per il modificatore no-capture ( /n ) nelle funzioni preg_* : in regex, i metacaratteri () indicano un gruppo di acquisizione. Ciò significa che vengono restituite tutte le corrispondenze per l'espressione all'interno della parentesi. PHP 8.2 aggiunge un modificatore no-capture ( /n ) per fermare questo comportamento.
5. Fai in modo che la famiglia iterator_*() accetti tutti gli iterabili: A partire da ora, la famiglia iterator_*() di PHP accetta solo \Traversables (cioè non sono consentiti array semplici). È inutilmente limitante e questa RFC lo risolve.

Riepilogo

PHP 8.2 si basa sugli enormi miglioramenti di PHP 8.0 e PHP 8.1, il che non è un'impresa facile. Riteniamo che le funzionalità più interessanti di PHP 8.2 siano i suoi nuovi tipi standalone, le proprietà di sola lettura e numerosi miglioramenti delle prestazioni.

Non vediamo l'ora di confrontare PHP 8.2 con vari framework PHP e CMS.

Assicurati di aggiungere questo post del blog ai segnalibri per riferimento futuro.

Quali funzionalità di PHP 8.2 sono le tue preferite? Quali deprecazioni sono le tue meno preferite? Per favore condividi i tuoi pensieri con la nostra community nei commenti!