![\"PHP](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-released.png\")
Siete pronti? Cominciamo!<\/p>\n
PHP JIT (Just in Time Compiler)<\/h2>\n
La funzionalit\u00e0 pi\u00f9 acclamata in arrivo con PHP 8 \u00e8 il Compiler Just-in-time (JIT)<\/strong>. Ma cos’\u00e8 JIT?<\/p>\n La proposta dell’RFC<\/a> descrive JIT come segue:<\/p>\n “PHP JIT \u00e8 implementato come parte quasi indipendente di OPcache. Pu\u00f2 essere abilitato\/disabilitato al momento della compilazione di PHP e al run-time. Quando \u00e8 abilitato, il codice nativo dei file PHP \u00e8 memorizzato in una regione aggiuntiva della memoria condivisa di OPcache e gli op_array\u2192opcodes[].handler(s) mantengono i puntatori sugli entry points del codice JIT.”<\/p><\/blockquote>\n Allora, come siamo arrivati a JIT e qual \u00e8 la differenza tra JIT e OPcache?<\/p>\n Per capire meglio cos’\u00e8 JIT per PHP, diamo una rapida occhiata a come viene eseguito\u00a0PHP<\/a> dal codice sorgente fino al risultato finale.<\/p>\n L’esecuzione di PHP consiste in una procedura in 4 fasi:<\/p>\n L’immagine che segue mostra una rappresentazione visuale della procedura di esecuzione di base di PHP.<\/p>\n Allora, in che modo OPcache rende PHP pi\u00f9 veloce? E cosa cambia nella procedura di esecuzione con JIT?<\/p>\n PHP \u00e8 un linguaggio interpretato. Ci\u00f2 significa che, quando viene eseguito uno script PHP, l’interprete analizza, compila ed esegue il codice pi\u00f9 e pi\u00f9 volte ad ogni richiesta. Ci\u00f2 pu\u00f2 comportare uno spreco di risorse della CPU<\/a>\u00a0e di tempo aggiuntivo.<\/p>\n Qui entra in gioco l’estensione OPcache<\/a>:<\/p>\n “OPcache migliora le prestazioni di PHP memorizzando il bytecode degli script precompilati nella memoria condivisa, eliminando cos\u00ec la necessit\u00e0 per PHP di caricare e analizzare gli script ad ogni richiesta.”<\/p><\/blockquote>\n Con OPcache abilitato, l’interprete PHP attraversa la procedura a 4 fasi di cui sopra solo la prima volta che lo script viene eseguito. Dato che i bytecode PHP sono memorizzati nella memoria condivisa, sono immediatamente disponibili come rappresentazione intermedia di basso livello e possono essere eseguiti subito sulla Zend VM.<\/p>\n A partire da PHP 5.5, l’estensione Zend OPcache \u00e8 disponibile di default e si pu\u00f2 verificare se questa \u00e8 configurata correttamente semplicemente\u00a0invocando OPcache \u00e8 stata recentemente migliorata con l’implementazione del preloading<\/a>, una nuova funzionalit\u00e0 di OPcache aggiunta con\u00a0PHP 7.4<\/a>. Il preloading fornisce un modo per memorizzare un insieme specifico di script nella memoria di OPcache “prima che venga eseguito qualsiasi codice applicativo<\/i>“, ma non porta un miglioramento tangibile delle prestazioni per le tipiche applicazioni basate sul web.<\/p>\n Potete leggere di pi\u00f9 sul precaricamento nella nostra introduzione a PHP 7.4<\/a>.<\/p>\n Con JIT, PHP fa un passo avanti.<\/p>\n Anche se gli opcode sono sotto forma di rappresentazione intermedia di basso livello, devono comunque essere compilati in codice macchina. JIT “non introduce alcuna forma aggiuntiva di rappresentazione intermedia (IR – Intermediate Representation)”, ma utilizza\u00a0DynASM<\/a> (Dynamic Assembler for code generation engines) per generare codice nativo direttamente dal byte-code PHP.<\/p>\n In breve, JIT traduce le parti calde del codice intermedio in codice macchina<\/strong>. Bypassando la compilazione, \u00e8 in grado di apportare notevoli miglioramenti nelle prestazioni e nell’utilizzo della memoria.<\/p>\n Zeev Surasky, co-autore della proposta di PHP JIT, mostra quanto sarebbero pi\u00f9 veloci i calcoli con JIT:<\/p>\n Ma JIT pu\u00f2 migliorare davvero le\u00a0prestazioni di WordPress<\/a>?<\/p>\n Secondo l’RFC di JIT, l’implementazione del compilatore just in time dovrebbe migliorare le prestazioni di PHP. Ma sperimenteremo davvero tali miglioramenti in applicazioni reali come WordPress?<\/p>\n I primi test mostrano che JIT renderebbe molto pi\u00f9 veloci i carichi di lavoro ad alta intensit\u00e0 di CPU, tuttavia, avverte l’RFC<\/a>:<\/p>\n “… come i precedenti tentativi – attualmente non sembra migliorare significativamente le applicazioni reali come WordPress (con opcache.jit=1235 326 req\/sec vs 315 req\/sec).<\/p>\n Si prevede uno sforzo ulteriore per migliorare JIT per le applicazioni real-life, utilizzando profilazione e ottimizzazioni speculative”.<\/p><\/blockquote>\n Con JIT abilitato, il codice non verrebbe eseguito dalla Zend VM, ma dalla CPU stessa, e questo migliorerebbe la velocit\u00e0 di calcolo. Le applicazioni web come\u00a0WordPress<\/a> si basano anche su altri fattori come\u00a0TTFB<\/a>, ottimizzazione del database<\/a>, richieste HTTP<\/a>, ecc.<\/p>\n Quindi, per quel che riguarda WordPress e applicazioni simili, non dovremmo aspettarci un grande incremento della velocit\u00e0 di esecuzione di PHP. Tuttavia, JIT potrebbe portare diversi benefici agli sviluppatori<\/a>.<\/p>\n Secondo Nikita Popov<\/a>:<\/p>\n “I vantaggi del compilatore JIT sono grossomodo (e come gi\u00e0 delineato nell’RFC):<\/p>\n Cos\u00ec, anche se JIT difficilmente porter\u00e0 enormi miglioramenti alle prestazioni di WordPress, porter\u00e0 PHP al livello successivo, permettendo di scrivere funzioni direttamente nel linguaggio.<\/p>\n Il lato negativo, tuttavia, sarebbe la maggiore complessit\u00e0 che potrebbe portare ad un aumento dei costi di manutenzione<\/a>, stabilit\u00e0 e debugging<\/a>. Secondo Dmitry Stogov:<\/p>\n “JIT \u00e8 estremamente semplice, ma in ogni caso aumenta il livello generale di complessit\u00e0 di PHP, comporter\u00e0 rischi di nuovi tipi di bug e costi di sviluppo e manutenzione”.<\/p><\/blockquote>\n La proposta di includere JIT in PHP 8 \u00e8 passata con 50 voti favorevoli e 2 contrari.<\/p>\n\n Oltre a JIT, con il rilascio di PHP 8 possiamo aspettarci molte altre funzionalit\u00e0 e miglioramenti. L’elenco che segue \u00e8 la nostra selezione delle prossime aggiunte e modifiche che dovrebbero rendere PHP pi\u00f9 affidabile ed efficiente.<\/p>\n Come risultato di una discussione in corso su come migliorare l’ergonomia degli oggetti in PHP<\/a>, la Constructor Property Promotion RFC<\/a> propone una nuova e pi\u00f9 concisa sintassi che semplifica la dichiarazione delle propriet\u00e0, rendendola pi\u00f9 breve e meno ridondante.<\/p>\n Questa proposta si riferisce solo ai promoted parameters<\/strong>, cio\u00e8 quei parametri di metodo preceduti dalle visibility keyword public<\/strong>, protected<\/strong> e private<\/strong>.<\/p>\n Attualmente, tutte le propriet\u00e0 devono essere ripetute pi\u00f9 volte (almeno quattro volte) prima di poter essere utilizzate con gli oggetti. Si consideri il seguente esempio riportato sull’RFC:<\/p>\n Secondo Nikita Popov, l’autore della RFC, dobbiamo scrivere il nome della propriet\u00e0 almeno quattro volte in tre posti diversi: la dichiarazione della propriet\u00e0, i parametri del costruttore e l’assegnazione della propriet\u00e0. Questa sintassi non \u00e8 particolarmente usabile, soprattutto nelle classi con un buon numero di propriet\u00e0 e nomi pi\u00f9 descrittivi.<\/p>\n Questa RFC propone di unire il costruttore e la definizione dei parametri. Cos\u00ec, a partire da PHP 8, abbiamo un modo pi\u00f9 usabile di dichiarare i parametri e il codice visto sopra pu\u00f2 cambiare come mostrato di seguito:<\/p>\n E questo \u00e8 tutto. Cos\u00ec abbiamo un nuovo modo di promuovere le propriet\u00e0 che \u00e8 pi\u00f9 breve, pi\u00f9 leggibile e meno soggetto a errori. Secondo Nikita<\/a>:<\/p>\n \u00c8 una semplice trasformazione sintattica che stiamo facendo. Ma questo riduce la quantit\u00e0 di codice boilerplate che si deve scrivere, in particolare per gli oggetti di valore…<\/p><\/blockquote>\n La dichiarazione di propriet\u00e0 viene trasformata come se avessimo dichiarato esplicitamente tali propriet\u00e0 e possiamo utilizzare la Reflection API<\/a> per effettuare un’analisi introspettiva delle definizioni delle propriet\u00e0 prima dell’esecuzione (si veda Desugaring<\/a>):<\/p>\n La Reflection (e altri meccanismi di introspezione) osserver\u00e0 lo stato dopo il desugaring. Ci\u00f2 significa che le propriet\u00e0 promosse appariranno allo stesso modo delle propriet\u00e0 dichiarate esplicitamente, e gli argomenti del costruttore promosso appariranno come argomenti ordinari del costruttore.<\/p><\/blockquote>\n Non abbiamo alcuna limitazione nell’utilizzo dell’ereditariet\u00e0 con la promozione dei parametri. In ogni caso, non c’\u00e8 una relazione particolare tra i costruttori di classi genitori e classi figlie. Secondo Nikita<\/a>:<\/p>\n Di solito, diciamo che i metodi devono sempre essere compatibili con il metodo della classe genitore. […] ma questa regola non vale per il costruttore. Quindi il costruttore appartiene realmente ad una singola classe, e non deve esserci in alcun modo compatibilit\u00e0 tra i costruttori della classe genitore e della classe figlia.<\/p><\/blockquote>\n Ecco un esempio:<\/p>\n Le propriet\u00e0 promosse sono consentite nei costruttori non astratti e nei trait, ma ci sono diverse limitazioni che vale la pena menzionare.<\/p>\n Le propriet\u00e0 promosse non sono ammesse nelle classi astratte e nelle interfacce:<\/p>\n Uno dei vincoli maggiori \u00e8 legato alla nullability. In precedenza, quando si utilizzava un tipo che non era esplicitamente nullable, ma con un valore predefinito nullo, il tipo era implicitamente nullable. Ma con i property type, non abbiamo questo comportamento implicito perch\u00e9 i parametri promossi richiedono una dichiarazione di propriet\u00e0, e il tipo nullable deve essere dichiarato esplicitamente. Si veda l’esempio seguente riportato nella RFC:<\/p>\n Dato che callable non \u00e8 un tipo supportato per le propriet\u00e0<\/a>, non ci \u00e8 permesso utilizzare il tipo callable nella promozione dei parametri:<\/p>\n Solo una visibility keyword pu\u00f2 essere utilizzata con i parametri promossi, quindi non \u00e8 consentito dichiarare le propriet\u00e0 del costruttore con la parola chiave Possiamo combinare propriet\u00e0 promosse e propriet\u00e0 esplicite nella stessa classe, ma le propriet\u00e0 non possono essere dichiarate due volte:<\/p>\n Il motivo \u00e8 che il tipo dichiarato \u00e8 diverso dal parametro variadico, che \u00e8 in realt\u00e0 un array:<\/p>\n Per una discussione approfondita della Costructor Property Promotion, ascoltate questa intervista a Nikita Popov<\/a>. Per una panoramica approfondita dell’ergonomia degli oggetti in PHP, si veda questo articolo<\/a> e la successiva intervista a Larry Garfield<\/a>.<\/p>\n I Trait<\/a> sono definiti come “un meccanismo per il riutilizzo del codice in linguaggi a single inheritance<\/em> come PHP”. Sono utilizzati per dichiarare metodi che possono essere usati in pi\u00f9 classi.<\/p>\n Un trait pu\u00f2 anche contenere metodi astratti. Questi metodi si limitano a dichiarare la firma del metodo, ma l’implementazione deve essere fatta all’interno della classe che utilizza il trait.<\/p>\n Secondo il\u00a0manuale PHP<\/a>,<\/p>\n “I trait supportano l’utilizzo di metodi astratti per imporre requisiti alla classe che li espone”.<\/p><\/blockquote>\n Ci\u00f2 significa anche che le firme dei metodi devono corrispondere. In altre parole, il tipo e il numero di argomenti richiesti\u00a0devono essere gli stessi<\/a>.<\/p>\n Ad ogni modo, secondo Nikita Popov<\/a>, autore dell’RFC, la convalida della firma \u00e8 attualmente applicata solo in modo irregolare:<\/p>\n Il seguente esempio di Nikita si riferisce al primo caso (firma non forzata):<\/p>\n Detto questo, questa RFC<\/a> propone di emettere sempre un errore fatale se il metodo che implementa non \u00e8 compatibile con il metodo astratto del trait, indipendentemente dalla sua origine:<\/p>\n Questa RFC \u00e8 stato approvato all’unanimit\u00e0.<\/p>\n In PHP, gli errori di ereditariet\u00e0 dovuti a firme di metodi incompatibili generano o un errore fatale o un warning a seconda di ci\u00f2 che causa l’errore.<\/p>\n Se una classe sta implementando un’interfaccia, le firme dei metodi incompatibili generano un errore fatale. Secondo la\u00a0documentazione delle Object Interface<\/a>:<\/p>\n “La classe che implementa l’interfaccia deve utilizzare una firma di metodo compatibile con l’LSP (Principio di Sostituzione di Liskov). Se non lo fa, si otterr\u00e0 un errore fatale.”<\/p><\/blockquote>\n Ecco un esempio di errore di ereditariet\u00e0 con un’interfaccia<\/a>:<\/p>\n In PHP 7.4, il codice di cui sopra avrebbe generato il seguente errore:<\/p>\n Una funzione in una child class<\/em> con una firma incompatibile genererebbe un warning. Si consideri il seguente codice tratto dall’RFC:<\/p>\n In PHP 7.4, il codice qui sopra non farebbe altro che generare un avviso:<\/p>\n Ora, questa RFC<\/a> propone di emettere sempre un errore fatale per le firme di metodo incompatibili. Con PHP 8, il codice che abbiamo visto in precedenza visualizzerebbe quanto segue:<\/p>\n In PHP, se un array inizia con un indice negativo ( In PHP 7.4 il risultato sarebbe il seguente:<\/p>\n Ora, questa RFC<\/a> propone di cambiare le cose in modo che il secondo indice sia In PHP 8, il codice di cui sopra risulterebbe nel seguente array:<\/p>\n Dunque, con PHP 8, gli array che iniziano con un indice negativo cambiano il loro comportamento. Per saperne di pi\u00f9 sulle retro-incompatibilit\u00e0 si legga\u00a0la RFC<\/a>.<\/p>\n Gli Union Types<\/a>\u00a0accettano valori che possono essere di diversi tipi. Attualmente, PHP non fornisce supporto per gli Union Types, con l’eccezione della sintassi del tipo Prima di PHP 8, gli Union Types potevano essere specificati solo nelle annotazioni phpdoc, come mostrato nell’esempio seguente tratto dall’RFC:<\/p>\n La RFC Union Types 2.0<\/a> propone di aggiungere il supporto per gli Union Type nelle firme delle funzioni, in modo da non fare pi\u00f9 affidamento sulla\u00a0documentazione in linea, ma definisce invece gli Union Types con la sintassi Come spiegato da Nikita Popov nella RFC,<\/p>\n “Il supporto degli Union Types nel linguaggio ci permette di spostare pi\u00f9 informazioni sui tipi da phpdoc delle firme delle funzioni, con i soliti vantaggi che questo comporta:<\/p>\n Gli Union Types supportano tutti i tipi disponibili, con alcune limitazioni:<\/p>\n Potete leggere di pi\u00f9 sugli\u00a0Union Types V2<\/a> nell’RFC.<\/p>\n Quando si passa un parametro di tipo illegale, le funzioni\u00a0interne<\/a> e quelle definite dall’utente<\/a> si comportano in modo diverso.<\/p>\n Le funzioni definite dall’utente generano un Questo risulterebbe nel seguente avviso:<\/p>\n Il comportamento sarebbe diverso se Questa situazione comporterebbe ad una serie di problemi ben illustrati nella sezione Issues<\/a> della\u00a0RFC<\/a>.<\/p>\n Per rimuovere queste incongruenze, questa RFC propone<\/a> far s\u00ec che le API interne di analisi dei parametri generino sempre un In PHP 8, il codice sopra riportato genera il seguente errore:<\/p>\n In PHP, Questa RFC<\/a> propone di convertire l’istruzione Si vedano i seguenti esempi tratti dall’RFC:<\/p>\n Una weak map \u00e8 una collezione di dati (oggetti) in cui le chiavi sono referenziate debolmente, il che significa che non viene impedito loro di eliminate (garbage collected).<\/p>\n PHP 7.4 ha aggiunto il supporto per le\u00a0weak reference<\/a> come modo per mantenere un riferimento ad un oggetto che non impedisce all’oggetto stesso di essere distrutto. Come sottolineato da Nikita Popov,<\/p>\n “Le weak reference grezze da soli sono di limitata utilit\u00e0 e le weak map nella pratica sono utilizzate molto pi\u00f9 spesso. Non \u00e8 possibile implementare un’efficiente weak map al top delle weak reference di PHP perch\u00e9 non \u00e8 prevista la possibilit\u00e0 di registrare una callback di distruzione”.<\/p><\/blockquote>\n Ecco perch\u00e9\u00a0questa RFC<\/a> introduce una classe Nei processi di lunga durata, ci\u00f2 eviterebbe perdite di memoria e migliorerebbe le prestazioni. Si veda questo esempio tratto dall’RFC:<\/p>\n Con PHP 8, il codice di cui sopra produrrebbe il seguente risultato (vedere\u00a0il codice in azione qui<\/a>):<\/p>\n Se si deregistra l’oggetto, la chiave viene automaticamente rimossa dalla weak map:<\/p>\n Adesso il risultato sarebbe il seguente:<\/p>\n\n
![\"Procedura](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/05\/processo-esecuzione-base-php.png\")
L’Estensione OPcache<\/h3>\n
![\"Procedura](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/05\/processo-esecuzione-php-opcache-abilitata.png\")
phpinfo()<\/code><\/a> da uno script sul proprio server o controllando il file php.ini (si vedano le\u00a0impostazioni di configurazione di OPcache<\/a>).<\/p>\n![\"Sezione](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2020\/05\/zend-sezione-opcache-pagina-phpinfo.jpg\")
Preloading<\/h3>\n
JIT \u2014 Just in Time Compiler<\/h3>\n
JIT per le Live Web Apps<\/h3>\n
![\"PHP](\"https:\/\/kinsta.com\/wp-content\/uploads\/2020\/05\/php-8-performance-diagram.png\")
\n
PHP 8: Miglioramenti e Nuove Funzionalit\u00e0<\/h2>\n
Constructor Property Promotion<\/h3>\n
class Point {\n public int $x;\n public int $y;\n public int $z;\n\n public function __construct(\n int $x = 0,\n int $y = 0,\n int $z = 0,\n ) {\n $this->x = $x;\n $this->y = $y;\n $this->z = $z;\n }\n}<\/code><\/pre>\nclass Point {\n public function __construct(\n public int $x = 0,\n public int $y = 0,\n public int $z = 0,\n ) {}\n}<\/code><\/pre>\n\/\/ before desugaring\nclass Point {\n public function __construct(public int $x = 0) {}\n}\n\n\/\/ after desugaring\nclass Point {\n public int $x;\n\n public function __construct(int $x = 0) {\n $this->x = $x;\n }\n}<\/code><\/pre>\nEreditariet\u00e0<\/h4>\n
class Test {\n public function __construct(\n public int $x = 0\n ) {}\n}\n\nclass Child extends Test {\n public function __construct(\n $x, \n public int $y = 0,\n public int $z = 0,\n ) {\n parent::__construct($x);\n }\n}<\/code><\/pre>\nCosa Non \u00c8 Consentito con la Promozione delle Propriet\u00e0<\/h4>\n
Costruttori Astratti<\/h5>\n
abstract class Test {\n \/\/ Error: Abstract constructor.\n abstract public function __construct(private $x);\n}\n \ninterface Test {\n \/\/ Error: Abstract constructor.\n public function __construct(private $x);\n}<\/code><\/pre>\nNullability<\/h5>\n
class Test {\n \/\/ Error: Using null default on non-nullable property\n public function __construct(public Type $prop = null) {}\n\n \/\/ Correct: Make the type explicitly nullable instead\n public function __construct(public ?Type $prop = null) {}\n}<\/code><\/pre>\nTipo Callable<\/h5>\n
class Test {\n \/\/ Error: Callable type not supported for properties.\n public function __construct(public callable $callback) {}\n}<\/code><\/pre>\nLa Keyword var Non \u00c8 Ammessa<\/h5>\n
var<\/code> (si veda il seguente esempio della RFC):<\/p>\nclass Test {\n \/\/ Error: \"var\" keyword is not supported.\n public function __construct(var $prop) {}\n}<\/code><\/pre>\nNon Sono Ammesse Duplicazioni<\/h5>\n
class Test {\n public string $prop;\n public int $explicitProp;\n\n \/\/ Correct\n public function __construct(public int $promotedProp, int $arg) {\n $this->explicitProp = $arg;\n }\n\n \/\/ Error: Redeclaration of property.\n public function __construct(public string $prop) {}\n}<\/code><\/pre>\nI Parametri Variadici Non Sono Ammessi<\/h5>\n
class Test {\n \/\/ Error: Variadic parameter.\n public function __construct(public string ...$strings) {}\n}<\/code><\/pre>\nUlteriori Letture<\/h4>\n
Validazione per i Metodi Astratti dei Trait<\/h3>\n
\n
\n
trait T {\n\tabstract public function test(int $x);\n}\n \nclass C {\n\tuse T;\n\n\t\/\/ Allowed, but shouldn't be due to invalid type.\n\tpublic function test(string $x) {}\n}<\/code><\/pre>\nFatal error: Declaration of C::test(string $x) must be compatible with T::test(int $x) in \/path\/to\/your\/test.php on line 10<\/code><\/pre>\nFirme di Metodi Incompatibili<\/h3>\n
interface I {\n\tpublic function method(array $a);\n}\nclass C implements I {\n\tpublic function method(int $a) {}\n}<\/code><\/pre>\nFatal error: Declaration of C::method(int $a) must be compatible with I::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nclass C1 {\n\tpublic function method(array $a) {}\n}\nclass C2 extends C1 {\n\tpublic function method(int $a) {}\n}<\/code><\/pre>\nWarning: Declaration of C2::method(int $a) should be compatible with C1::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nFatal error: Declaration of C2::method(int $a) must be compatible with C1::method(array $a) in \/path\/to\/your\/test.php on line 7<\/code><\/pre>\nArray che Iniziano con un Indice Negativo<\/h3>\n
start_index < 0<\/code>), gli indici successivi partiranno da 0 (maggiori informazioni su questo punto nella\u00a0documentazione di array_fill<\/code><\/a>).\u00a0Si consideri il seguente esempio:<\/p>\n$a = array_fill(-5, 4, true);\nvar_dump($a);<\/code><\/pre>\narray(4) {\n\t[-5]=>\n\tbool(true)\n\t[0]=>\n\tbool(true)\n\t[1]=>\n\tbool(true)\n\t[2]=>\n\tbool(true)\n}<\/code><\/pre>\nstart_index + 1<\/code>, qualunque sia il valore di start_index<\/code>.<\/p>\narray(4) {\n\t[-5]=>\n\tbool(true)\n\t[-4]=>\n\tbool(true)\n\t[-3]=>\n\tbool(true)\n\t[-2]=>\n\tbool(true)\n}<\/code><\/pre>\nUnion Types 2.0<\/h3>\n
?Type<\/code> e del tipo speciale iterabile<\/code>.<\/p>\nclass Number {\n\t\/**\n\t * @var int|float $number\n\t *\/\n\tprivate $number;\n\n\t\/**\n\t * @param int|float $number\n\t *\/\n\tpublic function setNumber($number) {\n\t\t$this->number = $number;\n\t}\n\n\t\/**\n\t * @return int|float\n\t *\/\n\tpublic function getNumber() {\n\t\treturn $this->number;\n\t}\n}<\/code><\/pre>\nT1|T2|....<\/code>:<\/p>\nclass Number {\n\tprivate int|float $number;\n\n\tpublic function setNumber(int|float $number): void {\n\t\t$this->number = $number;\n\t}\n\n\tpublic function getNumber(): int|float {\n\t\treturn $this->number;\n\t}\n}<\/code><\/pre>\n\n
\n
void<\/code> non pu\u00f2 essere parte di un’unione, in quanto void<\/code> significa che una funzione non restituisce alcun valore<\/a>.<\/li>\nnull<\/code> \u00e8 supportato solo negli Union Types, ma il suo utilizzo come tipo standalone non \u00e8 consentito.<\/li>\n?T<\/code>) \u00e8 permessa, che significa T|null<\/code>, ma non \u00e8 permesso includere la notazione ?T<\/code> negli Union Types (?T1|T2<\/code> non \u00e8 permessa e dovremmo usare invece T1|T2|null<\/code>).<\/li>\nstrpos()<\/code>, strstr()<\/code>, substr()<\/code>, ecc.) includono false<\/code> tra i possibili tipi di ritorno, \u00e8 supportato anche lo pseudotipo false<\/code>.<\/li>\n<\/ul>\nErrori di Tipo Coerenti per le Funzioni Interne<\/h3>\n
TypeError<\/code>, ma le funzioni interne si comportano in diversi modi, in base a diverse condizioni. In ogni caso, il comportamento tipico \u00e8 quello di emettere un avvertimento e restituire null<\/code>. Si consideri il seguente esempio in PHP 7.4:<\/p>\nvar_dump(strlen(new stdClass));<\/code><\/pre>\nWarning: strlen() expects parameter 1 to be string, object given in \/path\/to\/your\/test.php on line 4\nNULL<\/code><\/pre>\nstrict_types<\/code> \u00e8 abilitato, o se le informazioni sugli argomenti specificano i tipi. In tali scenari, l’errore del tipo viene rilevato e risulta in un TypeError<\/code>.<\/p>\nThrowError<\/code> in caso mancata corrispondenza dei tipi dei parametri.<\/p>\nFatal error: Uncaught TypeError: strlen(): Argument #1 ($str) must be of type string, object given in \/path\/to\/your\/test.php:4\nStack trace:\n#0 {main}\n thrown in \/path\/to\/your\/test.php on line 4<\/code><\/pre>\nthrow Come Espressione<\/h3>\n
throw<\/code> \u00e8 una dichiarazione<\/a>, quindi non \u00e8 possibile utilizzarlo in situazioni in cui \u00e8 consentita solo un’espressione<\/a>.<\/p>\nthrow<\/code><\/a> in un’espressione in modo che possa essere utilizzata in qualsiasi contesto in cui sono consentite le espressioni. Ad esempio, arrow function<\/a>, operatore null coalesce<\/a>, operatori ternari ed elvis,<\/a> ecc.<\/p>\n$callable = fn() => throw new Exception();\n\n\/\/ $value is non-nullable.\n$value = $nullableValue ?? throw new InvalidArgumentException();\n \n\/\/ $value is truthy.\n$value = $falsableValue ?: throw new InvalidArgumentException();<\/code><\/pre>\nWeak Maps<\/h3>\n
WeakMap<\/code> per creare oggetti da utilizzare come chiavi di weak map che possono essere distrutte e rimosse dalla weak map nel caso in cui non ci siano ulteriori riferimenti all’oggetto key.<\/p>\n$map = new WeakMap;\n$obj = new stdClass;\n$map[$obj] = 42;\nvar_dump($map);<\/code><\/pre>\nobject(WeakMap)#1 (1) {\n\t[0]=>\n\tarray(2) {\n\t\t[\"key\"]=>\n\t\tobject(stdClass)#2 (0) {\n\t\t}\n\t\t[\"value\"]=>\n\t\tint(42)\n\t}\n}<\/code><\/pre>\nunset($obj);\nvar_dump($map);<\/code><\/pre>\n