PHP 8.2 si fonda sulla base rinnovata da PHP 8.0 e PHP 8.1. Ora che è stato rilasciato PHP 8.2, analizziamo in dettaglio le novità: dalle nuove funzionalità, ai miglioramenti, alle deprecazioni e alle tante modifiche minori, analizziamo tutto.

Dal momento che PHP 8.2 è stato congelato il 19 luglio 2022, non ci si può aspettare alcuna aggiunta significativa a questo elenco.

Curiosi? Anche noi lo siamo.

Iniziamo!

Nuove Funzionalità e Miglioramenti di PHP 8.2

Iniziamo con l’esplorare tutte le novità di PHP 8.2. Si tratta di un elenco piuttosto ampio:

Nuove Classi readonly

PHP 8.1 ha introdotto la funzionereadonly per le proprietà delle classi. Ora, PHP 8.2 aggiunge il supporto per dichiarare l’intera classe come readonly.

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

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

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

Immaginate la stessa cosa con molte altre proprietà. Ora, con PHP 8.2, potete scrivere semplicemente questo:

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

Potete anche dichiarare classi astratte o finali come readonly. In questo caso, l’ordine delle parole chiave non ha importanza.

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

Potete anche dichiarare una classe readonly senza proprietà. In questo modo si evitano le proprietà dinamiche e si permette alle classi figlie di dichiarare esplicitamente le loro proprietà readonly.

Inoltre, le classi readonly possono contenere solo proprietà tipizzate: la stessa regola per la dichiarazione delle proprietà individuali di sola lettura.

Potete usare la proprietà mixed type se non potete dichiarare una proprietà strettamente tipizzata.

Se provate a dichiarare una classe readonly senza una proprietà tipizzata, otterrete un errore irreversibile:

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

Inoltre, non potete dichiarare readonly per alcune funzioni di PHP:

Il tentativo di dichiarare una di queste funzioni come readonly provocherà un errore di parsing.

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

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

PHP 8.2 depreca anche le proprietà dinamiche (ne parleremo più avanti). Tuttavia, non è possibile impedire l’aggiunta di proprietà dinamiche a una classe. Tuttavia, se lo fate per una classe readonly otterrete un errore irreversibile.

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

Consentire true, false e null come Tipi Indipendenti

PHP include già tipi scalari come int, string e bool. Questo è stato ampliato in PHP 8.0 con l’aggiunta dei tipi union, che permettono 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, ma non erano ammessi come tipi a sé stanti.

Se si provava a dichiarare false o null come tipi indipendenti, senza che facessero parte di un tipo di unione, si otteneva 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 supporta l’uso di false e null come tipi autonomi. Con questa aggiunta, il sistema di tipi di PHP è più espressivo e completo. Ora potete dichiarare con precisione i tipi di ritorno, di parametro e di proprietà.

Inoltre, PHP non include ancora il tipo true, che sembra essere la naturale controparte del tipo false. PHP 8.2 risolve questo problema e aggiunge il supporto per il tipo true . Non consente la coercizione, esattamente come il tipo false.

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

Tipi di Disjunctive Normal Form (DNF)

La Disjunctive Normal Form (DNF) è un modo standardizzato di organizzare le espressioni booleane. Consiste in una disgiunzione di congiunzioni – in termini booleani, si tratta di un OR di AND.

L’applicazione del DNF alle dichiarazioni di tipo consente di scrivere tipi combinati di Union e Intersection che il parser può gestire. La nuova funzione dei tipi DNF di PHP 8.2 è semplice ma potente se usata correttamente.

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

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, potete eseguire dichiarazioni di tipo per proprietà, parametri e valori di ritorno 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 in forma DNF. Dichiarandole come tali si otterrà un errore di parsing. Ma potete sempre riscriverle 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

Dovete notare che ogni segmento di un tipo DNF deve essere unico. Per esempio, dichiarare (A&B)|(B&A) non è valido perché i due segmenti OR sono logicamente uguali.

Inoltre, non sono ammessi nemmeno i segmenti che sono sottoinsiemi rigorosi di un altro segmento. Questo perché il sottoinsieme avrà già tutte le istanze del sottoinsieme, rendendo superfluo l’uso del DNF.

Ridurre i Parametri Sensibili nei Back-Trace

Come quasi tutti i linguaggi di programmazione, PHP permette di tracciare lo stack delle chiamate in qualsiasi punto dell’esecuzione del codice. Il tracciamento dello stack facilita il debug del codice per correggere gli errori e i 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.

Tracciamento delle transazioni lente di WooCommerce con Kinsta APM.
Tracciamento delle transazioni lente di WooCommerce con Kinsta APM.

L’esecuzione di una traccia dello stack non interrompe l’esecuzione del programma. In genere, la maggior parte delle tracce di stack vengono eseguite in background e registrate in modo silenzioso per poter essere controllate in seguito, se necessario.

Tuttavia, alcune di queste dettagliate tracce di stack di PHP possono rappresentare un inconveniente se vengono condivise con servizi di terze parti, solitamente per l’analisi dei log degli errori, il tracciamento degli errori, ecc. Queste tracce di stack possono includere informazioni sensibili come nomi utente, password e variabili d’ambiente.

Questa proposta RFC ne fornisce un esempio:

Un “colpevole” comune è 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. In questo modo, quando la connessione al database fallisce, la traccia dello stack include 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 il nuovo attributo \SensitiveParameter. Qualsiasi parametro contrassegnato come sensibile non verrà elencato nelle backtrace. In questo modo, potrete condividerli senza problemi con servizi di terze parti.

Ecco un esempio semplice 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 generate un backtrace, qualsiasi parametro con l’attributo \SensitiveParameter verrà sostituito con un oggetto \SensitiveParameterValue e il suo valore reale non verrà mai memorizzato nel trace. L’oggetto SensitiveParameterValue incapsula il valore reale del parametro, se ne avete bisogno per qualsiasi motivo.

Nuova Funzione mysqli_execute_query e Metodo mysqli::execute_query

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

PHP 8.2 rende più semplice l’esecuzione di query MySQLi parametrizzate grazie alla nuova funzione mysqli_execute_query($sql, $params) e al metodo mysqli::execute_query.

Essenzialmente, questa nuova funzione è una combinazione delle funzioni mysqli_prepare(), mysqli_execute() e mysqli_stmt_get_result(). Con questa funzione, la query MySQLi viene preparata, vincolata (se si passano dei parametri) ed eseguita all’interno della funzione stessa. Se la query viene eseguita correttamente, restituirà un oggetto mysqli_result. Se non ha successo, restituirà false.

La proposta RFC fornisce un esempio semplice ma efficace:

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

Recuperare le Proprietà di enum nelle Espressioni di const

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

Il motivo principale di questa nuova funzionalità è che non è possibile usare gli oggetti di enum in alcuni punti, come le chiavi degli array. In questo caso, dovrete ripetere il valore del caso enum solo per poterlo utilizzare.

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

Ciò significa che il codice seguente è ora valido:

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

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

Consentire le Costanti nei Traits

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

Attualmente, i Traits permettono di definire solo metodi e proprietà, ma non le costanti. Ciò significa che non potete definire gli invarianti previsti da un Traits all’interno del Traits stesso. Per aggirare questa limitazione, dovete definire le costanti nella classe che lo compone o in un’interfaccia implementata dalla classe che lo compone.

Questa RFC propone di consentire la definizione di costanti nei Traits. Queste costanti possono essere definite proprio come le costanti di una classe. Questo esempio tratto direttamente dalla RFC chiarisce il 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 Traits sono incorporate nella definizione della classe che li compone, come le definizioni delle proprietà e dei metodi di un Traits. Inoltre hanno restrizioni simili a quelle delle proprietà dei Traits. Come indicato nell’RFC, questa proposta – sebbene sia un buon inizio – necessita di ulteriore lavoro per perfezionare la funzione.

Deprecazioni in PHP 8.2

Possiamo ora passare a esplorare tutte le deprecazioni di PHP 8.2. L’elenco non è così ampio come le nuove funzionalità:

Proprietà Dinamiche Deprecate (e Nuovo Attributo #[AllowDynamicProperties] )

Fino a PHP 8.1, era possibile impostare e recuperare dinamicamente proprietà di classe 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 dato che PHP consente le proprietà dinamiche, potete impostarla al di fuori della dichiarazione della classe. Questo è il suo più grande – e forse l’unico – vantaggio.

Le proprietà dinamiche permettono di creare bug e comportamenti inaspettati nel vostro codice. Per esempio, se commettete un errore nel dichiarare una proprietà della classe al di fuori di essa, è facile perderne traccia, soprattutto durante il debug di eventuali errori all’interno della classe stessa.

A partire da PHP 8.2, le proprietà dinamiche sono deprecate. L’impostazione di un valore a una proprietà di classe non dichiarata emetterà un avviso di deprecazione la prima volta che la proprietà verrà impostata.

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, a partire da PHP 9.0, l’impostazione di una proprietà dinamica emette un errore ErrorException.

Se il vostro codice è pieno di proprietà dinamiche – e molto codice PHP lo è – e se volete evitare questi avvisi di deprecazione dopo l’aggiornamento a PHP 8.2, potete usare il nuovo attributo #[AllowDynamicProperties] di PHP 8.2 per consentire le proprietà dinamiche 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 l’RFC, le classi contrassegnate come #[AllowDynamicProperties], così come le loro classi figlie, possono continuare a usare le proprietà dinamiche senza essere deprecate o rimosse.

Considerate inoltre che, in PHP 8.2, l’unica classe in bundle contrassegnata come #[AllowDynamicProperties] è stdClass. Inoltre, le proprietà a cui si accede tramite i magic methods PHP __get() o __set() non sono considerate proprietà dinamiche e quindi non riceveranno un avviso di deprecazione.

Deprecate i Callables Parzialmente Supportati

Un’altra modifica di PHP 8.2, anche se con un impatto più trascurabile, è la deprecazione dei callables parzialmente supportati.

Queste callables sono definite parzialmente supportate perché non è possibile interagire con esse direttamente tramite $callable(). Potete raggiungerle solo con la funzione call_user_func($callable). L’elenco di tali callables non è lungo:

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

A partire da PHP 8.2, qualsiasi tentativo di invocare tali callables – come per esempio tramite le funzioni call_user_func() o array_map() – produrrà un avviso di deprecazione.

La RFC originale fornisce una solida motivazione alla base di questa deprecazione:

A parte gli ultimi due casi, tutti questi callables dipendono dal contesto. Il metodo a cui "self::method" fa riferimento dipende dalla classe da cui viene effettuata la chiamata o la verifica della callability. In pratica, questo vale anche per gli ultimi due casi, se utilizzati nella forma di [new Foo, "parent::method"].

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

Come previsto dalla RFC originale, la funzione is_callable() e il tipo callable continueranno ad accettare queste callable come eccezioni. Ma solo fino a quando il loro supporto non sarà rimosso completamente a partire da PHP 9.0.

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

È bello vedere come PHP si stia muovendo per avere un tipo callable ben definito.

Deprecate le Funzioni #utf8_encode() e utf8_decode()

Le funzioni incorporate di PHP utf8_encode() e utf8_decode() convertono le stringhe codificate in ISO-8859-1 (“Latin 1”) da e verso 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 “Windows Code Page 1252”

Inoltre, di solito viene visualizzato Mojibake quando queste funzioni non riescono a convertire correttamente una stringa. La mancanza di messaggi di errore rende difficile individuarli, soprattutto in un mare di testo altrimenti leggibile.

PHP 8.2 ha deprecato le funzioni #utf8_encode() e utf8_decode() . Se le invocate, vedrete questi avvisi di deprecazione:

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

La RFC suggerisce di usare le estensioni supportate da PHP come mbstring, iconv e intl.

Deprecata l’Interpolazione di Stringhe di ${}

PHP permette di incorporare variabili nelle stringhe con doppi apici (") e heredoc (<<<) in diversi modi:

  1. Incorporare direttamente le variabili “$foo”
  2. Con parentesi graffe all’esterno della variabile – “{$foo}”
  3. Con le parentesi graffe dopo il segno del dollaro “${foo}”
  4. Variabili – “${expr}” – equivalente all’uso di (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 le ultime due modalità di interpolazione delle stringhe.

In futuro dovreste evitare di interpolare le stringhe in questo modo:

"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 saranno aggiornate per lanciare un’eccezione di errore.

Deprecate le Funzioni mbstring per le Entità Base64/QPrint/Uuencode/HTML

Le funzioni mbstring (multi-byte string) di PHP ci aiutano a lavorare con Unicode, entità HTML e altre codifiche di testo precedenti.

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

Per quanto riguarda le entità HTML, PHP dispone di funzioni integrate – htmlspecialchars() e htmlentities() – per gestirle meglio. Per esempio, a differenza di mbstring, queste funzioni convertono anche i caratteri <. >, e & in entità HTML.

Inoltre, PHP migliora continuamente le sue funzioni integrate, come nel caso di PHP 8.1 con le 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
  • HTML-ENTITIES
  • html (alias di HTML-ENTITIES)
  • Quoted-Printable
  • qprint (alias di Quoted-Printable)

A partire da PHP 8.2, l’utilizzo di mbstring per la codifica/decodifica di uno qualsiasi dei suddetti elementi emetterà un avviso di deprecazione. PHP 9.0 rimuoverà completamente il supporto di mbstring per queste codifiche.

Altri Cambiamenti Minori in PHP 8.2

Infine, possiamo parlare dei cambiamenti minori di PHP 8.2, tra cui le caratteristiche e le funzionalità rimosse.

Rimosso il Supporto per libmysql da mysqli

Attualmente, PHP permette ai driver mysqli e PDO_mysql di compilare le librerie mysqlnd e libmysql. Tuttavia, il driver predefinito e consigliato da PHP 5.4 è mysqlnd.

Entrambi i driver hanno molti vantaggi e svantaggi. Tuttavia, la rimozione del supporto per uno di essi – idealmente, la rimozione di libmysql in quanto non è quello predefinito – semplificherà il codice e i test unitari di PHP.

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

  • Viene fornito in bundle con PHP
  • Usa la gestione della memoria di PHP per monitorare l’utilizzo della memoria e
    migliorare le prestazioni
  • Fornisce funzioni di qualità della vita (per esempio get_result())
  • Restituisce valori numerici utilizzando i tipi nativi di PHP
  • La sua funzionalità non dipende dalla libreria esterna
  • Funzionalità plugin opzionale
  • Supporta le query asincrone

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

  • Possibilità di auto-riconnessione ( 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 di PHP, molti test falliti, perdite di memoria, funzionalità diverse tra le varie versioni, ecc.

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

Se volete aggiungere una funzionalità che è disponibile solo con libmysql, dovrete aggiungerla esplicitamente a mysqlnd come richiesta di funzionalità. Inoltre, non potete aggiungere la connessione automatica.

Conversione di Casi Indipendente dalla Lingua Locale

Prima di PHP 8.0, il locale di PHP veniva ereditato dall’ambiente di sistema. Ma questo poteva causare un problema in alcuni casi limite.

L’impostazione della lingua durante l’installazione di Linux imposta la lingua dell’interfaccia utente appropriata per i comandi integrati. Tuttavia, cambia inaspettatamente anche il funzionamento della libreria C per la gestione delle stringhe.

Per esempio, se durante l’installazione di Linux avete selezionato la lingua “turca” o “kazaka”, vedrete che chiamando toupper('i') per ottenere l’equivalente maiuscolo otterrete la I maiuscola tratteggiata (U+0130, İ).

PHP 8.0 ha eliminato questa anomalia impostando il locale predefinito su “C”, a meno che l’utente non lo cambi esplicitamente tramite setlocale().

PHP 8.2 si spinge oltre, eliminando la sensibilità del locale dalle conversioni di maiuscole e minuscole. Questa RFC modifica principalmente le funzioni strtolower(), strtoupper() e le funzioni correlate. Leggete l’RFC per un elenco di tutte le funzioni interessate.

In alternativa, se volete usare la conversione di maiuscole e minuscole localizzata, potete usare mb_strtolower().

Miglioramento dell’Estensione Casuale

PHP sta pianificando una revisione della sua funzionalità random.

Al momento, la funzionalità casuale di PHP si basa molto sullo stato di Mersenne Twister. Tuttavia, questo stato è implicitamente memorizzato nell’area globale di PHP: non c’è modo per un utente di accedervi. L’aggiunta di funzioni di randomizzazione tra la fase iniziale di seeding e l’uso previsto comporterebbe la rottura del codice.

La manutenzione di questo codice può essere ancora più complicata se il vostro codice usa pacchetti esterni.

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

Pertanto, l’utilizzo delle funzioni integrate di PHP – shuffle(), str_shuffle(), array_rand() – non è consigliato se avete bisogno di numeri casuali crittograficamente sicuri. In questi casi, dovrete implementare una nuova funzione utilizzando random_int() o funzioni simili.

Tuttavia, dopo l’inizio delle votazioni sono stati sollevati diversi problemi con questa RFC. Questa battuta d’arresto ha costretto il team di PHP ad annotare tutti i problemi in un RFC separato, con un’opzione di voto creata per ogni problema. Decideranno di procedere solo dopo aver raggiunto un consenso.

Altre RFC in PHP 8.2

PHP 8.2 include anche molte nuove funzioni e modifiche minori. Le citiamo di seguito con i link alle risorse aggiuntive:

  1. Nuova funzione curl_upkeep: PHP 8.2 aggiunge questa nuova funzione alla sua estensione Curl. Richiama la funzione curl_easy_upkeep() in libcurl, la libreria C sottostante che l’estensione Curl di PHP utilizza.
  2. Nuova funzione ini_parse_quantity: Le direttive INI di PHP accettano dimensioni di dati con un suffisso moltiplicatore. Per esempio, potete scrivere 25 Megabyte come 25M, o 42 Gigabyte come 42G. Questi suffissi sono comuni nei file INI di PHP ma sono poco diffusi altrove. Questa nuova funzione analizza i valori INI di PHP e restituisce la loro dimensione 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 eseguite la stessa azione più volte e volete registrare il picco di utilizzo della memoria di ogni esecuzione.
  4. Supporto per il modifer no-capture (/n) nelle funzioni di preg_*: Nelle regex, il metacarattere () indica un gruppo di cattura. Ciò significa che vengono restituite tutte le corrispondenze dell’espressione all’interno della parentesi. PHP 8.2 aggiunge un modifer no-capture (/n) per impedire questo comportamento.
  5. La famiglia iterator_*() accetta tutti gli iterabili: Al momento, la famiglia iterator_*() di PHP accetta solo \Traversables (cioè non sono ammessi array semplici). Si tratta di una limitazione non necessaria e questa RFC la risolve.

Riepilogo

PHP 8.2 si basa sugli enormi miglioramenti apportati da PHP 8.0 e PHP 8.1, e non è un’impresa facile. Le caratteristiche più interessanti di PHP 8.2 sono i nuovi tipi standalone, le proprietà readonly e i numerosi miglioramenti delle prestazioni.

Non vediamo l’ora di confrontare PHP 8.2 con diversi framework e CMS PHP.

Mettete tra i preferiti questo articolo per poterlo consultare in futuro.

Quali sono le caratteristiche di PHP 8.2 che preferite? Quali sono le deprecazioni che vi piacciono di più? Condividete la vostra opzione con la comunità nella sezione commenti!

Salman Ravoof

Salman Ravoof é uno sviluppatore web autodidatta, uno scrittore, un creatore e un grande ammiratore del Free and Open Source Software (FOSS). Oltre alla tecnologia, è appassionato di scienza, filosofia, fotografia, arte, gatti e cibo. Per saperne di più su di lui, visitate il suo sito web o contattate Salman su X.