PHP 8.4 in Symfony praktisch nutzen: Property Hooks, Asymmetric Visibility

1. Warum PHP 8.4 fuer Symfony-Teams jetzt relevant ist

PHP 8.4 ist keine reine Wartungsversion, sondern bringt mit Property Hooks und Asymmetric Visibility zwei Sprachfeatures, die den taeglichen Code in Symfony-Projekten direkt betreffen. Wer heute Entities, DTOs oder Value Objects schreibt, kennt das Muster: private Eigenschaft, ein Getter, ein Setter mit Validierung, oft dreimal so viele Zeilen wie eigentlich noetig. PHP 8.4 reduziert genau diesen Boilerplate, ohne dass Symfony selbst dafuer angepasst werden muss, denn die Features wirken auf Sprachebene und sind mit dem bestehenden Component-System vollstaendig kompatibel.

Der zweite Grund, sich jetzt mit PHP 8.4 zu beschaeftigen, ist der Support-Zeitplan. Symfony 7.x unterstuetzt PHP 8.4 offiziell, und die aktive Unterstuetzung fuer aeltere PHP-Versionen laeuft schrittweise aus. Ein Projekt, das heute auf PHP 8.2 verharrt, verliert nicht nur Sicherheits-Patches frueher, sondern auch die Moeglichkeit, neue Symfony-Komponenten ohne Kompatibilitaetsschicht zu nutzen. PHP 8.4 in Symfony einzufuehren ist damit weniger eine Kuer als ein planbarer Teil der technischen Schuldenpflege.

Dieser Artikel zeigt konkret, welche PHP 8.4 Features in Symfony-Projekten den groessten Hebel haben, wie man Deprecations vor dem Upgrade findet, und wie Rector und PHPStan die Migration automatisieren, statt sie zu einem manuellen Fleissjob zu machen. Jeder Abschnitt enthaelt lauffaehige Beispiele aus echten Symfony-Strukturen: Entities, Serializer-DTOs und Konfigurationsklassen.

2. Property Hooks: Getter und Setter ohne Boilerplate

Property Hooks sind das auffaelligste PHP 8.4 Feature fuer Symfony-Entwickler. Statt eine private Eigenschaft mit separaten get/set-Methoden zu kapseln, definiert man Hooks direkt an der Property. Ein get-Hook laeuft beim Lesen, ein set-Hook beim Schreiben, und beide koennen den Wert transformieren oder validieren, bevor er tatsaechlich gespeichert wird. Das ist besonders in Doctrine-Entities nuetzlich, wo Validierung und Normalisierung bisher oft in eigene Setter-Methoden ausgelagert wurden.

Der Vorteil gegenueber klassischen Gettern und Settern liegt nicht nur in der Zeilenzahl, sondern auch darin, dass die Property selbst weiterhin wie eine normale Eigenschaft angesprochen wird, also $product->price = 1999 statt $product->setPrice(1999). Fuer bestehenden Code, der bereits mit Gettern und Settern arbeitet, ist das kein Bruch, denn Property Hooks lassen sich schrittweise einfuehren, ohne die oeffentliche API einer Klasse sofort zu aendern. In der Praxis migriert man zuerst die Klassen mit der meisten Validierungslogik, weil dort der Effekt am groessten ist.

<?php
declare(strict_types=1);

namespace App\Entity;

use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity]
class Product
{
    private int $priceCents = 0;

    // Property Hook: validation runs on every write, no separate setter needed
    public int $price {
        get => (int) round($this->priceCents / 100);
        set {
            if ($value < 0) {
                throw new \InvalidArgumentException('Price cannot be negative');
            }
            $this->priceCents = $value * 100;
        }
    }

    #[ORM\Column(type: 'string', length: 255)]
    public string $name {
        set(string $value) {
            $this->name = trim($value);
        }
    }
}

$product = new Product();
$product->price = 1999;   // triggers the set hook, validates and stores cents
echo $product->price;    // triggers the get hook, returns 1999

Ein Detail, das beim Einstieg in PHP 8.4 Property Hooks oft uebersehen wird: Hooks koennen nicht auf statischen Properties definiert werden, und ein get-Hook ohne passenden set-Hook macht die Property faktisch nur lesbar von aussen, was virtuelle, berechnete Properties elegant ersetzt, die vorher als reine Getter-Methode implementiert waren. Fuer Symfony-Serializer-DTOs bedeutet das: berechnete Felder wie ein fullName aus Vor- und Nachname lassen sich als echte Property ausdruecken, die der Serializer ohne zusaetzliche Normalizer-Konfiguration korrekt erkennt.

3. Asymmetric Visibility: kontrollierte Veraenderbarkeit

Asymmetric Visibility loest ein Problem, das in Symfony-DTOs und Value Objects besonders haeufig auftritt: eine Property soll von aussen lesbar, aber nur von innen schreibbar sein. Vor PHP 8.4 brauchte man dafuer entweder readonly, was jede spaetere Aenderung verbietet, oder eine private Property mit einem oeffentlichen Getter. Mit public private(set) laesst sich jetzt genau die Semantik ausdruecken, die man eigentlich meint: von aussen nur lesen, von innen aendern, ganz ohne Getter-Methode.

Fuer Symfony-Anwendungen ist das besonders bei Aggregaten und Domain-Objekten relevant, die ihren internen Zustand aendern, ohne diese Aenderung nach aussen als oeffentliche Setter-Methode freizugeben. Ein Bestellstatus etwa soll nur ueber definierte Methoden wie markAsShipped() geaendert werden koennen, aber von aussen jederzeit lesbar sein. Asymmetric Visibility macht diese Regel zu einem Sprachfeature statt zu einer Konvention, die im Code-Review durchgesetzt werden muss.

<?php
declare(strict_types=1);

namespace App\Domain;

final class Order
{
    // Readable from outside, only writable from within this class
    public private(set) string $status = 'pending';

    public private(set) \DateTimeImmutable $updatedAt;

    public function __construct(
        public readonly string $id,
    ) {
        $this->updatedAt = new \DateTimeImmutable();
    }

    public function markAsShipped(): void
    {
        $this->status = 'shipped';
        $this->updatedAt = new \DateTimeImmutable();
    }
}

$order = new Order('order-123');
echo $order->status;       // fine, reading is allowed
$order->markAsShipped();
// $order->status = 'shipped'; // Fatal error: cannot modify from outside

Ein haeufiger Fehler beim Umstieg: Asymmetric Visibility mit einer voll auf readonly gesetzten Klasse zu verwechseln. readonly erlaubt genau eine Zuweisung, danach ist die Property fuer immer eingefroren, auch fuer die eigene Klasse. private(set) erlaubt beliebig viele Aenderungen, solange sie aus der eigenen Klasse kommen. Fuer Value Objects, die nach der Konstruktion nie mehr veraendert werden sollen, bleibt readonly korrekt. Fuer Domain-Objekte mit kontrolliertem Lebenszyklus ist private(set) das treffendere PHP 8.4 Feature.

4. Neue Array-Funktionen im Alltag

Neben den grossen Sprachfeatures bringt PHP 8.4 auch kleinere, aber im Alltag spuerbare Verbesserungen: array_find(), array_any() und array_all() ersetzen Muster, die vorher mit array_filter() plus reset() oder mit einer manuellen foreach-Schleife geloest wurden. array_find() gibt das erste Element zurueck, das ein Callback erfuellt, oder null, wenn keins passt, ohne dass man die gesamte Liste erst filtert und dann das erste Element separat extrahiert.

In Symfony-Controllern und Services, die haeufig ueber Collections von Entities oder DTOs iterieren, reduziert das den Code spuerbar. array_any() und array_all() ersetzen den Klassiker count(array_filter(...)) > 0 beziehungsweise count(array_filter(...)) === count(...) durch eine einzige, klar benannte Funktion, die zudem frueh abbricht, sobald das Ergebnis feststeht, statt die komplette Liste zu durchlaufen.

<?php
declare(strict_types=1);

/** @var Product[] $products */

// Before PHP 8.4: filter, then grab the first element
$filtered = array_filter($products, fn (Product $p) => $p->price > 5000);
$expensive = reset($filtered) ?: null;

// PHP 8.4: array_find stops at the first match, no intermediate array
$expensive = array_find(
    $products,
    fn (Product $p) => $p->price > 5000,
);

// array_any: true as soon as one element matches, short-circuits
$hasOutOfStock = array_any(
    $products,
    fn (Product $p) => $p->stock === 0,
);

// array_all: true only if every element matches
$allActive = array_all(
    $products,
    fn (Product $p) => $p->isActive,
);

Wichtig fuer bestehende Symfony-Projekte: Diese Funktionen sind reine Ergaenzungen, kein Ersatz, der bestehenden Code brechen wuerde. Ein schrittweises PHP 8.4 Upgrade kann alte array_filter-Muster stehen lassen und neue Stellen direkt mit den neuen Funktionen schreiben, was Reviews erleichtert, weil sich Diffs auf tatsaechlich veraenderten Code beschraenken, statt aus reiner Konsistenz ganze Dateien umzuschreiben.

5. Deprecations erkennen und vermeiden

Jedes PHP 8.4 Upgrade bringt neben neuen Features auch neue Deprecation-Warnungen, die in Symfony-Projekten gerne uebersehen werden, weil sie im Produktionsbetrieb standardmaessig nicht geloggt werden. Implizit nullable Parameter, also ein Typehint wie string $value = null ohne explizites ?string, sind seit PHP 8.4 deprecated und sollten vor dem Upgrade bereinigt werden, weil sie in einer kommenden Version zu einem Fehler statt einer Warnung werden.

Der zuverlaessigste Weg, Deprecations vor dem produktiven PHP 8.4 Rollout zu finden, ist die Symfony-Testsuite mit aktivierter error_reporting(E_ALL)-Konfiguration laufen zu lassen und den symfony/phpunit-bridge zu nutzen, der Deprecations sammelt und am Ende des Testlaufs als Bericht ausgibt, statt sie stillschweigend zu verschlucken. Wer diesen Bericht in der CI-Pipeline als Pflichtschritt einbaut, verhindert, dass sich neue Deprecations unbemerkt anhaeufen.

<?php
declare(strict_types=1);

// Deprecated since PHP 8.4: implicit nullable without explicit ?
function formatPrice(string $currency = null): string
{
    return $currency ?? 'EUR';
}

// Correct: explicit nullable type
function formatPriceFixed(?string $currency = null): string
{
    return $currency ?? 'EUR';
}

// phpunit.xml.dist: surface deprecations instead of hiding them
// <phpunit bootstrap="tests/bootstrap.php">
//   <php>
//     <env name="SYMFONY_DEPRECATIONS_HELPER" value="max[self]=0"/>
//   </php>
// </phpunit>

Die Umgebungsvariable SYMFONY_DEPRECATIONS_HELPER mit max[self]=0 lasst den Testlauf fehlschlagen, sobald der eigene Code eine neue Deprecation erzeugt, waehrend Deprecations aus Drittanbieter-Paketen separat gezaehlt werden. Diese Trennung ist wichtig, weil man selten sofort Einfluss auf jede Bundle-Abhaengigkeit hat, aber sehr wohl auf den eigenen Anwendungscode, der fuer ein sauberes PHP 8.4 Upgrade als erstes bereinigt werden sollte.

6. Symfony-Komponenten, die von PHP 8.4 profitieren

Der Symfony Serializer profitiert direkt von Property Hooks, weil berechnete oder normalisierte Properties jetzt ohne zusaetzliche Normalizer-Klassen auskommen. Ein DTO mit einem set-Hook, der eingehende Strings trimmt und normalisiert, verhaelt sich beim Deserialisieren aus JSON genauso wie bei manueller Instanziierung, weil der Hook unabhaengig vom Aufrufer greift. Das reduziert die Zahl der Custom Normalizer, die man bisher fuer einfache Transformationen schreiben musste.

Auch der DependencyInjection-Container profitiert indirekt: Asymmetric Visibility erlaubt, Service-Konfigurationsobjekte so zu bauen, dass sie nach der Kompilierung des Containers effektiv unveraenderlich sind, ohne auf volles readonly angewiesen zu sein, was bei Objekten mit spaeter Initialisierung durch Compiler Passes bisher zu Problemen fuehrte. Der Symfony Validator kann Property Hooks nutzen, um Constraint-Pruefungen direkt an der Property zu verankern, statt sie ausschliesslich ueber Attribute und externe Validator-Klassen zu regeln, was bei einfachen Invarianten den Code naeher an der eigentlichen Regel haelt.

Diese Verbesserungen erfordern keine Aenderung an Symfony selbst, weil das Framework PHP-Sprachfeatures durchreicht, statt sie zu abstrahieren. Ein Team, das PHP 8.4 in Symfony einfuehrt, profitiert also sofort, ohne auf ein Symfony-Minor-Release warten zu muessen, das explizite Unterstuetzung nachreicht.

7. Composer und Docker-Images vorbereiten

Bevor PHP 8.4 produktiv genutzt werden kann, muss die composer.json die neue Version zulassen und alle Abhaengigkeiten muessen kompatibel sein. Die platform-Konfiguration in Composer hilft, lokal exakt die Zielversion zu simulieren, auch wenn die Entwicklungsumgebung noch auf einer aelteren PHP-Version laeuft, was besonders in gemischten Teams mit unterschiedlichen lokalen Setups nuetzlich ist.

{
    "require": {
        "php": ">=8.4",
        "symfony/framework-bundle": "^7.2"
    },
    "config": {
        "platform": {
            "php": "8.4.0"
        },
        "sort-packages": true
    },
    "scripts": {
        "check-deprecations": [
            "@php bin/phpunit --configuration phpunit.xml.dist"
        ]
    }
}

Fuer Docker-Images bedeutet der Umstieg auf PHP 8.4 in der Regel nur eine Aenderung der Basis-Image-Version, etwa von php:8.3-fpm auf php:8.4-fpm, sofern alle genutzten PHP-Extensions bereits fuer PHP 8.4 gebaut sind. Wichtig ist, das Image zunaechst in einer Staging-Umgebung zu bauen und die komplette Test-Suite dort laufen zu lassen, bevor die Produktions-Pipeline auf PHP 8.4 umgestellt wird, weil Extension-Kompatibilitaet nicht immer aus der Composer-Ebene sichtbar ist.

8. Rector und PHPStan fuer automatisierte Migration

Manuelles Durchsuchen eines grossen Symfony-Codebestands nach Stellen, die von PHP 8.4 profitieren koennten, ist ineffizient und fehleranfaellig. Rector bringt seit Version 1.2 fertige Regelsaetze fuer PHP 8.4, die etwa klassische Getter/Setter-Paare automatisch in Property Hooks umwandeln, sofern das Muster eindeutig genug ist. Das reduziert manuelle Migration auf die Faelle, in denen Rector aus Sicherheitsgruenden nichts automatisch aendert.

<?php
declare(strict_types=1);

use Rector\Config\RectorConfig;
use Rector\Php84\Rector\Property\PropertyHookRector;
use Rector\Set\ValueObject\LevelSetList;

return static function (RectorConfig $rectorConfig): void {
    $rectorConfig->paths([__DIR__ . '/src']);

    $rectorConfig->sets([
        LevelSetList::UP_TO_PHP_84,
    ]);

    // Optional: enable individual rules explicitly for a controlled rollout
    $rectorConfig->rule(PropertyHookRector::class);
};

PHPStan ergaenzt Rector, indem es nach der automatisierten Transformation prueft, ob Typen weiterhin konsistent sind, besonders bei Property Hooks, deren get- und set-Typen theoretisch voneinander abweichen koennen. Ein Level-5-Lauf nach jedem Rector-Batch faengt Faelle ab, in denen die automatische Umwandlung zwar syntaktisch korrekt war, aber die urspruengliche Validierungslogik im Setter nicht vollstaendig in den set-Hook uebernommen wurde. Diese Kombination aus Rector fuer die Transformation und PHPStan fuer die Verifikation macht ein PHP 8.4 Upgrade in einem grossen Symfony-Monolithen praktikabel, statt Wochen an manueller Nacharbeit zu erfordern.

9. Rollout-Strategie im Team

Ein PHP 8.4 Rollout in einem laufenden Symfony-Projekt sollte in klar getrennten Phasen ablaufen: Erst die Laufzeitumgebung auf PHP 8.4 heben und die komplette Testsuite gruen bekommen, ohne neue Sprachfeatures zu nutzen. Erst danach beginnt man, neue Features wie Property Hooks in neuem Code einzusetzen, waehrend bestehender Code unveraendert bleibt, bis er ohnehin angefasst wird. Diese Trennung verhindert, dass ein einziger grosser Pull Request sowohl Infrastruktur- als auch Stilaenderungen mischt und dadurch fuer Reviewer unlesbar wird.

Die folgende Tabelle vergleicht die gaengigen Migrationsansaetze fuer PHP 8.4 in bestehenden Symfony-Projekten.

In der Praxis kombinieren erfolgreiche Teams die letzten drei Zeilen der Tabelle: Laufzeit zuerst heben, dann Rector fuer klar automatisierbare Muster einsetzen, und parallel dazu neue Klassen von Anfang an mit PHP 8.4 Features schreiben. Der Big-Bang-Ansatz aus der ersten Zeile bleibt fast immer die schlechtere Wahl, weil er Reviewbarkeit und Rollback-Faehigkeit gleichzeitig verschlechtert.

10. Zusammenfassung

PHP 8.4 in Symfony reduziert Boilerplate an genau den Stellen, die im Alltag am meisten Code binden: Getter und Setter werden durch Property Hooks ersetzt, kontrollierte Veraenderbarkeit wird mit Asymmetric Visibility zum Sprachfeature statt zur Konvention, und neue Array-Funktionen wie array_find() ersetzen umstaendliche Filter-Ketten. Diese Verbesserungen wirken direkt in Doctrine-Entities, Serializer-DTOs und Domain-Objekten, ohne dass Symfony selbst dafuer angepasst werden muss.

Der sichere Weg zu PHP 8.4 fuehrt ueber drei Schritte: zuerst Deprecations mit dem symfony/phpunit-bridge sichtbar machen und beheben, dann die Laufzeitumgebung heben und die Testsuite gruen bekommen, und erst danach neue Features mit Rector-gestuetzter Automatisierung schrittweise einfuehren. PHPStan sichert jeden Schritt ab, indem es Typinkonsistenzen nach automatisierten Transformationen aufdeckt. Wer diese Reihenfolge einhaelt, bringt PHP 8.4 ohne Produktionsrisiko in bestehende Symfony-Projekte.

11. FAQ: PHP 8.4 in Symfony