PHP 8.4: le novità che cambiano davvero il modo di scrivere codice

PHP 8.4 è stato rilasciato a novembre 2024 e nella mia esperienza è l'aggiornamento con il maggior impatto sul modo di scrivere codice PHP dal rilascio di PHP 8.0 nel 2020. Non per una singola feature rivoluzionaria, ma per un insieme di miglioramenti che, adottati insieme, eliminano interi pattern di boilerplate che gli sviluppatori PHP trascinano da anni: property hooks che sostituiscono getter e setter, asymmetric visibility che permette di esporre proprietà in lettura ma non in scrittura, nuove funzioni array che eliminano il ricorso a array_map con callback brutte, e lazy objects nativi che sostituiscono i proxy generati. Ho aggiornato tre codebase a PHP 8.4 nei primi sei mesi dalla release - un'applicazione Laravel 11 da 60.000 righe, un'API Symfony 7 con 45 endpoint, e un gestionale custom senza framework - e in ciascuna ho potuto semplificare significativamente il codice sfruttando le nuove feature del linguaggio.

L'aggiornamento del runtime in sé è stato semplice in tutti e tre i casi: PHP 8.4 mantiene un'eccellente backward compatibility con PHP 8.3, e le uniche breaking change che ho incontrato sono state deprecation diventate errori (l'uso implicito di variabili globali, il passaggio per riferimento a funzioni che non lo accettano) e il cambiamento di comportamento di alcune funzioni di stringa che ora lanciano ValueError su input invalidi invece di restituire false. In totale, le incompatibilità hanno richiesto meno di 2 ore di lavoro per codebase - un costo irrisorio rispetto al valore delle nuove feature.

Property hooks: la fine dei getter e setter boilerplate

Le property hooks sono la novità più attesa di PHP 8.4: permettono di definire la logica di lettura (get) e scrittura (set) di una proprietà direttamente nella dichiarazione della proprietà, senza bisogno di metodi getter e setter separati. Il risultato è una riduzione drastica del boilerplate in DTO, Value Object e model - le classi dove il pattern getter/setter è più pervasivo.

Prima di PHP 8.4, un DTO con validazione nel setter richiedeva questo codice:

// PRIMA: DTO con getter/setter tradizionali (PHP 8.3)
class Indirizzo
{
    private string $cap;
    private string $provincia;

    public function getCap(): string { return $this->cap; }

    public function setCap(string $cap): void
    {
        if (!preg_match('/^\d{5}$/', $cap)) {
            throw new \InvalidArgumentException("CAP non valido: {$cap}");
        }
        $this->cap = $cap;
    }

    public function getProvincia(): string { return $this->provincia; }

    public function setProvincia(string $provincia): void
    {
        if (strlen($provincia) !== 2) {
            throw new \InvalidArgumentException("Provincia deve essere 2 caratteri");
        }
        $this->provincia = strtoupper($provincia);
    }
}

Con PHP 8.4, lo stesso DTO diventa:

// DOPO: DTO con property hooks (PHP 8.4)
class Indirizzo
{
    public string $cap {
        set(string $value) {
            if (!preg_match('/^\d{5}$/', $value)) {
                throw new \InvalidArgumentException("CAP non valido: {$value}");
            }
            $this->cap = $value;
        }
    }

    public string $provincia {
        set(string $value) {
            if (strlen($value) !== 2) {
                throw new \InvalidArgumentException("Provincia deve essere 2 caratteri");
            }
            $this->provincia = strtoupper($value);
        }
    }
}

La differenza non è solo nelle righe di codice risparmiato - è nella localizzazione della logica. Con i getter/setter, la validazione vive in un metodo separato dalla dichiarazione della proprietà; con le property hooks, la validazione è nella proprietà. Quando leggi il codice, vedi immediatamente che $cap ha un vincolo di formato - non devi cercare un metodo setCap altrove nel file. Per classi con 10-15 proprietà (comuni nei DTO di e-commerce con indirizzo di spedizione, dati di fatturazione, preferenze di consegna), il risparmio in righe è del 40-50% e il miglioramento in leggibilità è proporzionale.

Nel mio profilo professionale trovi il dettaglio dell'esperienza nell'adozione delle nuove feature PHP in codebase di produzione - un'area dove il tempismo è importante: adottare troppo presto espone a bug delle prime release, adottare troppo tardi significa accumulare debito tecnico per inerzia. A sei mesi dalla release, PHP 8.4 è stabile e maturo per la produzione.

Asymmetric visibility: proprietà leggibili dall'esterno, scrivibili solo dall'interno

La seconda novità con impatto pratico immediato è l'asymmetric visibility: la possibilità di dichiarare una proprietà con visibilità diversa per la lettura e per la scrittura. Il caso d'uso più comune è una proprietà che deve essere leggibile dall'esterno ma scrivibile solo dalla classe stessa - un pattern che prima richiedeva una proprietà privata con un getter pubblico.

Con PHP 8.4 la sintassi è compatta e intuitiva: public private(set) string $nome significa "leggibile da chiunque, scrivibile solo dalla classe." Questo pattern è particolarmente utile per le entità di dominio dove le proprietà vengono impostate nel costruttore o in metodi di business e non devono essere modificabili dall'esterno:

class Ordine
{
    // Leggibile dall'esterno, scrivibile solo dalla classe
    public private(set) int $id;
    public private(set) StatoOrdine $stato;
    public private(set) float $totale;
    public private(set) \DateTimeImmutable $creatoIl;

    public function __construct(int $id, float $totale)
    {
        $this->id = $id;
        $this->totale = $totale;
        $this->stato = StatoOrdine::Bozza;
        $this->creatoIl = new \DateTimeImmutable();
    }

    // Lo stato può cambiare solo attraverso metodi di business
    public function conferma(): void
    {
        if (!$this->stato->puòTransitareA(StatoOrdine::Confermato)) {
            throw new TransizioneNonAmmessaException();
        }
        $this->stato = StatoOrdine::Confermato;
    }
}

// Utilizzo: lettura libera, scrittura protetta
$ordine = new Ordine(1, 150.50);
echo $ordine->totale;        // OK: 150.50
$ordine->totale = 200.00;    // ERRORE: Cannot modify private(set) property
$ordine->conferma();          // OK: modifica lo stato attraverso il metodo di business

La combinazione di asymmetric visibility con gli enum PHP che ho descritto nel mio articolo dedicato produce un modello di dominio che è contemporaneamente espressivo (le proprietà sono accessibili direttamente senza getter), sicuro (le modifiche passano attraverso metodi di business con validazione), e type-safe (gli enum garantiscono che lo stato sia sempre un valore ammesso). È il modello che adotto come standard in ogni nuovo progetto PHP dal 2025 in poi.

Nuove funzioni array e le breaking change da gestire

PHP 8.4 introduce array_find(), array_find_key(), array_any() e array_all() - quattro funzioni che eliminano pattern comuni di array_filter + reset o di loop foreach con flag booleani. La più utile nella mia esperienza è array_find(): restituisce il primo elemento di un array che soddisfa un predicato, senza dover filtrare l'intero array e poi prendere il primo risultato. Su un array di 10.000 prodotti, la differenza di performance tra array_filter($prodotti, fn($p) => $p->codice === 'ABC')[0] ?? null (filtra tutto l'array) e array_find($prodotti, fn($p) => $p->codice === 'ABC') (si ferma al primo match) è significativa - ma il vantaggio principale è la leggibilità: array_find comunica l'intento "trova il primo che soddisfa" molto meglio di array_filter + reset.

Le breaking change che ho incontrato nell'aggiornamento delle tre codebase sono state poche ma richiedono attenzione. La più insidiosa è il cambiamento di comportamento di round() quando riceve un valore non numerico: in PHP 8.3 restituiva 0, in PHP 8.4 lancia un TypeError. Nel gestionale custom, un campo del database che conteneva stringhe vuote (per importi non ancora calcolati) veniva passato a round() senza conversione esplicita - funzionava silenziosamente in PHP 8.3 e ha iniziato a lanciare eccezioni in PHP 8.4. La fix è un cast esplicito (float) prima della chiamata - un cambiamento minimale ma che richiede di trovare tutti i punti del codice dove round() riceve input potenzialmente non numerico.

L'altra breaking change rilevante è che le estensioni PECL compilate per PHP 8.3 devono essere ricompilate per PHP 8.4 - pecl install rdkafka e pecl install redis devono essere rieseguiti. Se usi Docker, l'immagine base php:8.4-fpm include solo le estensioni core, e tutte le estensioni PECL devono essere reinstallate nel Dockerfile. Ho documentato l'ottimizzazione dei Dockerfile per applicazioni PHP in un articolo dedicato dove il processo di compilazione delle estensioni PECL è una delle fasi del multi-stage build.

L'impatto su Laravel e Symfony: cosa cambia nei framework

L'adozione di PHP 8.4 ha un impatto diretto anche sul modo in cui i framework principali evolvono. Laravel 12, rilasciato nel primo trimestre 2026, sfrutta già le property hooks internamente in diverse classi del framework - e le API pubbliche di Laravel sono progettate per essere compatibili con le nuove feature. Se usi Laravel Eloquent, i cast delle proprietà possono ora beneficiare delle property hooks per aggiungere logica di trasformazione direttamente nella dichiarazione del model, senza passare attraverso l'array $casts o i metodi accessor/mutator tradizionali. La combinazione di property hooks con il casting Eloquent è particolarmente elegante per i campi che richiedono trasformazione bidirezionale - ad esempio un campo telefono che deve essere normalizzato alla scrittura (rimuovere spazi e prefissi) e formattato alla lettura (aggiungere il prefisso internazionale).

Symfony 7.2 supporta PHP 8.4 dalla release e il componente di serializzazione (symfony/serializer) sfrutta le property hooks per la de/serializzazione dei DTO - il che elimina la necessità di configurare normalizer custom per proprietà che richiedono trasformazione durante la serializzazione. Il dependency injection container di Symfony riconosce le proprietà con asymmetric visibility e le gestisce correttamente nell'autowiring - una proprietà public private(set) viene iniettata dal container (che ha accesso alla scrittura durante la costruzione) ma non può essere sovrascritta dall'esterno dopo l'iniezione.

Un aspetto che merita attenzione è la retrocompatibilità con PHPStan e Psalm. Entrambi gli strumenti di analisi statica supportano PHP 8.4 dalla release, ma le property hooks richiedono una versione minima specifica: PHPStan 1.12+ e Psalm 6.0+. Se la tua pipeline CI/CD include analisi statica (e dovrebbe), verifica che la versione dello strumento sia compatibile prima di adottare le nuove feature nel codice - un'annotazione @property che descrive un hook in un formato che PHPStan non capisce produce falsi positivi che inquinano il report di analisi.

L'impatto complessivo di PHP 8.4 sulle tre codebase che ho aggiornato è quantificabile: il DTO layer dell'applicazione Laravel è passato da 2.400 righe a 1.600 righe (riduzione del 33%), i model Symfony con getter/setter sono stati semplificati del 25%, e il numero di metodi per classe nel gestionale custom è sceso da una media di 18 a una media di 12 - con la stessa funzionalità, ma espressa in modo più diretto e con meno indirezione. Il tempo di onboarding di un nuovo sviluppatore sulla codebase è anche diminuito perché il codice con property hooks e asymmetric visibility è auto-documentante: le regole di accesso e trasformazione sono visibili nella dichiarazione della proprietà, non nascoste in metodi che bisogna cercare nel file.

PHP 8.4 non è un aggiornamento opzionale per chi lavora con il linguaggio in produzione - è un aggiornamento che migliora concretamente la qualità del codice che scrivi ogni giorno. Le property hooks e l'asymmetric visibility da soli giustificano l'aggiornamento, e la combinazione con gli enum e i lazy objects (che ho trattato in un articolo dedicato) produce un linguaggio che nel 2025 è più espressivo, più sicuro e più performante di quanto sia mai stato. Se le tue applicazioni sono ancora su PHP 8.2 o 8.3 e stai rimandando l'aggiornamento, contattami per una valutazione di compatibilità: in mezza giornata testiamo il runtime su PHP 8.4, identifichiamo le breaking change, e definiamo il piano di aggiornamento con le feature da adottare subito e quelle da adottare gradualmente. L'investimento tipico per l'aggiornamento - mezza giornata per il runtime, due-tre giorni per il refactoring delle feature - si ripaga nel primo mese con il tempo risparmiato nella scrittura e nella manutenzione del codice, e produce un miglioramento permanente nella qualità e nella sicurezza della codebase che ogni sviluppatore del team apprezza dal primo giorno. L'esperienza accumulata sui tre aggiornamenti che ho gestito nel primo semestre 2025 conferma che il momento migliore per aggiornare è adesso - i framework sono pronti, gli strumenti di analisi statica sono compatibili, e la comunità ha già identificato e documentato le breaking change residue.