First-Class-Callable-Syntax in PHP: Methodenreferenzen ohne Strings und Arrays

1. Einordnung: das Problem mit String- und Array-Callables vor PHP 8.1

PHP kennt seit frueheren Versionen den Sammelbegriff Callable fuer alles, was sich aufrufen laesst. Bis PHP 8.0 gab es dafuer im Wesentlichen zwei Notationen: einen String wie 'strlen', der eine globale Funktion referenziert, und ein Array wie [$objekt, 'methode'] beziehungsweise ['Klasse', 'methode'], das eine Instanzmethode oder eine statische Methode referenziert. Beide Formen funktionieren zuverlaessig, behandeln den Methodennamen aber als reinen String, den PHP erst zur Laufzeit auswertet.

Genau darin liegt das strukturelle Problem: Der Parser sieht in ['Mailer', 'send'] lediglich zwei String-Literale. Er kann zur Kompilierzeit nicht pruefen, ob die Klasse Mailer ueberhaupt existiert, ob sie eine Methode send besitzt oder ob deren Signatur zum Aufrufkontext passt. Ein Tippfehler wie ['Mailer', 'sedn'] faellt erst beim tatsaechlichen Aufruf auf, oft mitten im Produktivbetrieb, mit einem "Call to undefined method"-Fehler. IDEs koennen solche Strings nicht zuverlaessig referenzieren, wodurch ein Rename-Refactoring der Methode zu einer stillen Falle wird: Der String-Callable bleibt unveraendert und bricht erst zur Laufzeit.

PHP 8.1 loest genau dieses Problem mit der First-Class-Callable-Syntax. Statt Methodenreferenzen als Strings oder Arrays zu kodieren, werden sie zu echten Ausdruecken, die der Parser sofort aufloest. Die folgenden Abschnitte gehen im Detail auf Syntax, Unterschiede zu bestehenden Mechanismen, Sichtbarkeit, Performance und die praktische Migration bestehenden Codes ein.

2. Die Syntax im Detail: funcName(...), $obj->methode(...), Klasse::methode(...)

Die First-Class-Callable-Syntax besteht aus einem Funktions- oder Methodenaufruf, bei dem statt konkreter Argumente exakt drei Punkte in den Klammern stehen: funcName(...). Diese drei Punkte sind kein Spread-Operator und kein variadischer Aufruf, sondern ein eigenes Token, das der Parser als Anweisung interpretiert, eine Closure aus der Referenz zu erzeugen. Die Klammern duerfen ausschliesslich die drei Punkte enthalten, jede zusaetzliche Angabe von Argumenten fuehrt zu einem Parse-Fehler.

Die Syntax funktioniert in vier grundlegenden Formen: als globale Funktion (strlen(...)), als Instanzmethode ($objekt->methode(...)), als statische Methode (Klasse::methode(...)) und innerhalb von Klassen zusaetzlich ueber self::methode(...), parent::methode(...) sowie static::methode(...). In jedem Fall erzeugt PHP intern ein Closure-Objekt, das die vollstaendige Signatur der Zielfunktion uebernimmt, inklusive Default-Werten, variadischen Parametern und Named Arguments.

Ein Detail, das leicht uebersehen wird: Der Nullsafe-Operator laesst sich nicht mit First-Class-Callable-Syntax kombinieren. Ein Ausdruck wie $objekt?->methode(...) ist syntaktisch nicht erlaubt und fuehrt zu einem Fatal Error. Wer eine moeglicherweise null-wertige Referenz callable machen will, muss die Nullpruefung vorher explizit durchfuehren, bevor die First-Class-Callable-Syntax angewendet wird.

<?php

declare(strict_types=1);

// Global function reference: parser resolves "strlen" immediately
$length = strlen(...);
echo $length('First-Class-Callable-Syntax'); // 27

// Instance method reference, $this is bound automatically
final class Mailer
{
    public function send(string $to, string $subject): bool
    {
        // ... sending logic omitted
        return true;
    }
}

$mailer = new Mailer();
$sendFn = $mailer->send(...);
$sendFn('dev@mironsoft.de', 'Deploy fertig');

// Static method reference, no $this bound
final class Formatter
{
    public static function currency(float $amount): string
    {
        return number_format($amount, 2) . ' EUR';
    }
}

$formatFn = Formatter::currency(...);
echo $formatFn(1299.9);

// Nullsafe operator cannot be combined with first-class callable syntax:
// $mailer?->send(...); // Fatal error: Cannot use nullsafe operator here

3. Unterschied zu Closure::fromCallable() und manueller Closure-Erzeugung

Vor PHP 8.1 war Closure::fromCallable() die naechstliegende Alternative, um aus einer Methodenreferenz eine wiederverwendbare Closure zu erzeugen. Der entscheidende Unterschied: Closure::fromCallable([$objekt, 'methode']) nimmt weiterhin einen klassischen Callable-Wert entgegen, also ein Array aus Objekt und String. Die Aufloesung dieses Strings passiert intern weiterhin zur Laufzeit, lediglich verpackt in ein wiederverwendbares Closure-Objekt. Fuer den Parser und jedes statische Analyse-Tool bleibt der Methodenname ein undurchsichtiger String.

Die First-Class-Callable-Syntax $objekt->methode(...) hingegen wird vom Parser als eigener Ausdruckstyp erkannt und direkt aufgeloest, ohne den Umweg ueber einen Callable-Wert. Beide Varianten erzeugen zur Laufzeit ein funktional aequivalentes Closure-Objekt, doch nur die zweite ist fuer IDEs und Analyzer als tatsaechlicher Methodenaufruf sichtbar.

Vor PHP 8.1 wurden Closures haeufig manuell nachgebaut, etwa mit function (float $net) use ($calc) { return $calc->withTax($net); }. Dieser Ansatz zwingt dazu, die komplette Zielsignatur inklusive Default-Werten, variadischen Parametern und Named Arguments von Hand nachzubilden, was bei jeder Signaturaenderung der Ursprungsmethode zu einer weiteren Fehlerquelle wird. Die First-Class-Callable-Syntax uebernimmt die Signatur automatisch und bleibt damit synchron zur Zielmethode, ohne manuelle Pflege.

<?php

declare(strict_types=1);

final class PriceCalculator
{
    public function withTax(float $net): float
    {
        return $net * 1.19;
    }
}

$calc = new PriceCalculator();

// Old style: string/array callable resolved through Closure::fromCallable()
$oldClosure = Closure::fromCallable([$calc, 'withTax']);

// First-class callable syntax: parser resolves the reference directly
$newClosure = $calc->withTax(...);

// Both behave identically at call time, but only the second is
// visible to static analysis and IDE refactoring tools
var_dump($oldClosure(100.0) === $newClosure(100.0)); // true

// Manual closure before PHP 8.1 had to re-declare the full signature,
// including variadics and default values
$manualClosure = function (float $net) use ($calc): float {
    return $calc->withTax($net);
};

4. Vorteile fuer Static Analysis und IDE-Refactoring

Statische Analyse-Tools wie PHPStan und Psalm koennen bei First-Class-Callable-Syntax die referenzierte Funktion oder Methode wie einen normalen Aufruf pruefen. Existiert die Funktion nicht, stimmt die Anzahl der Parameter nicht oder ist die Methode aus dem aktuellen Kontext nicht sichtbar, meldet das Analyse-Tool den Fehler bereits beim Build, lange bevor der Code in Produktion laeuft. Bei einem String-Callable wie 'strln' bleibt der Tippfehler dagegen unentdeckt, bis die Funktion tatsaechlich aufgerufen wird.

Auch IDEs wie PhpStorm behandeln $objekt->methode(...) wie einen regulaeren Methodenaufruf: "Go to Declaration", "Find Usages" und "Rename" funktionieren zuverlaessig, weil die Referenz syntaktisch eindeutig an die Methodendeklaration gebunden ist. Bei String- und Array-Callables ist die IDE auf Heuristiken angewiesen, die bei dynamisch zusammengesetzten Strings oder bei Namespaces mit mehreren gleichnamigen Klassen regelmaessig versagen.

Ein weiterer Effekt betrifft die Typinferenz: Bei array_map(strval(...), $werte) kennt der Analyzer die Signatur von strval und kann den Rueckgabetyp des gesamten Ausdrucks als list<string> ableiten. Bei array_map('strval', $werte) muss der Analyzer den String-Namen erst gegen die interne Funktionstabelle aufloesen, was in komplexeren Faellen, etwa bei Callables aus Variablen, gar nicht mehr moeglich ist.

5. Einsatz mit array_map, array_filter und usort

Die praktischste Anwendung der First-Class-Callable-Syntax liegt in Funktionen hoeherer Ordnung wie array_map, array_filter und usort, die in nahezu jeder Codebasis vorkommen. Statt array_map('strtoupper', $array) schreibt man array_map(strtoupper(...), $array), ohne funktionale Aenderung, aber mit vollstaendiger Sichtbarkeit fuer Analyzer und IDE.

Bei Instanzmethoden zeigt sich der Vorteil noch deutlicher: array_filter($items, [$validator, 'isValid']) wird zu array_filter($items, $validator->isValid(...)). Der Callable ist an dieser Stelle nicht mehr nur ein Array aus Objekt und String, sondern eine direkt an die Methode gebundene Closure, deren Existenz und Sichtbarkeit sofort geprueft werden.

Auch bei usort mit Vergleichsfunktionen ersetzt die First-Class-Callable-Syntax das haeufig fehleranfaellige usort($items, [$this, 'compareByPriority']) durch usort($items, $this->compareByPriority(...)). Die Lesbarkeit steigt, weil der Ausdruck wie ein gewoehnlicher Methodenaufruf aussieht, nur ohne die abschliessenden Argumente.

<?php

declare(strict_types=1);

$prices = [19.99, 5.5, 120.0];

// Old style: function name as string, opaque to static analysis
$roundedOld = array_map('round', $prices);

// First-class callable syntax: parser verifies "round" exists
$roundedNew = array_map(round(...), $prices);

final class Validator
{
    public function isPositive(float $value): bool
    {
        return $value > 0.0;
    }
}

$validator = new Validator();

// Old style: array callable, string method name
$validOld = array_filter($prices, [$validator, 'isPositive']);

// First-class callable syntax: bound instance method, statically checked
$validNew = array_filter($prices, $validator->isPositive(...));

final class Sorter
{
    public function byValueDescending(float $a, float $b): int
    {
        return $b <=> $a;
    }
}

$sorter = new Sorter();
usort($prices, $sorter->byValueDescending(...));

6. Gebundenes $this und Sichtbarkeit bei privaten und protected Methoden

$objekt->methode(...) erzeugt eine Closure, die an $objekt gebunden ist. Innerhalb der Closure verhaelt sich $this exakt so, als wuerde man die Methode direkt am Objekt aufrufen, funktional aequivalent zu Closure::fromCallable([$objekt, 'methode']). Der Unterschied liegt nicht im Bindungsverhalten, sondern im Zeitpunkt der Sichtbarkeitspruefung.

Bei einem Array-Callable wie [$objekt, 'privateMethode'] wird die Sichtbarkeit erst geprueft, wenn der Callable tatsaechlich aufgerufen wird, etwa tief innerhalb von array_map. Ist die Methode aus dem Aufrufkontext heraus nicht sichtbar, schlaegt der Aufruf mit einem Fehler fehl, der raeumlich weit vom eigentlichen Erstellungsort entfernt auftritt. Bei First-Class-Callable-Syntax pruef PHP die Sichtbarkeit bereits im Moment, in dem $objekt->privateMethode(...) ausgewertet wird, also direkt an der Stelle, an der die Referenz entsteht. Fehler werden dadurch fruehzeitiger und naeher am eigentlichen Problem sichtbar.

Private und protected Methoden lassen sich ueber $this->privateHelper(...) innerhalb der eigenen Klasse referenzieren, ohne sie oeffentlich zugaenglich machen zu muessen. Das ermoeglicht saubere interne Callback-Strukturen, etwa fuer Event-Handler oder Pipeline-Schritte, ohne die oeffentliche Schnittstelle der Klasse mit zusaetzlichen public-Methoden zu belasten, die ausschliesslich fuer die interne Verwendung als Callable gedacht waren.

7. First-Class-Callables fuer statische Methoden und Interfaces

Klasse::methode(...) referenziert eine statische Methode und erzeugt eine ungebundene Closure ohne $this-Kontext. Das entspricht dem klassischen ['Klasse', 'methode']-Callable, ist aber genauso statisch pruefbar wie die Instanzvariante. Innerhalb von Klassenmethoden funktionieren zusaetzlich self::methode(...), parent::methode(...) und static::methode(...), wobei static:: die spaete statische Bindung respektiert und die Closure an die tatsaechlich aufrufende Klasse bindet, nicht an die Klasse, in der die Methode ursprnglich definiert wurde.

Eine First-Class-Callable-Referenz auf eine Interface-Methode ohne konkreten Kontext ist nicht moeglich, da ein Interface selbst keine Implementierung besitzt, die der Parser aufloesen koennte. Ist eine Variable dagegen gegen ein Interface typisiert, funktioniert $handler->methode(...) problemlos, weil zur Laufzeit die konkrete Implementierungsklasse hinter der Variable steht. Das macht die First-Class-Callable-Syntax kompatibel mit dem Strategy-Pattern und mit ueber Dependency Injection eingebundenen Interface-Implementierungen.

Ein Detail bei static::methode(...) in Vererbungshierarchien: Die Closure wird zum Zeitpunkt ihrer Erzeugung an die zu diesem Zeitpunkt aktuelle Klasse gebunden. Ruft eine Kindklasse eine geerbte Methode auf, die intern static::methode(...) verwendet, referenziert die entstehende Closure die ueberschriebene Methode der Kindklasse, nicht die Originalimplementierung der Elternklasse. Polymorphie bleibt also erhalten.

<?php

declare(strict_types=1);

interface PaymentHandlerInterface
{
    public function capture(int $orderId): bool;
}

final class StripeHandler implements PaymentHandlerInterface
{
    public function capture(int $orderId): bool
    {
        // ... capture logic omitted
        return true;
    }

    public static function refund(int $orderId): bool
    {
        // ... refund logic omitted
        return true;
    }
}

// Static method reference: unbound closure, no $this
$refundFn = StripeHandler::refund(...);
$refundFn(4711);

// Interface-typed variable: resolves to the concrete implementation at runtime
function processOrder(PaymentHandlerInterface $handler, int $orderId): void
{
    $captureFn = $handler->capture(...);
    $captureFn($orderId);
}

processOrder(new StripeHandler(), 4711);

final class OrderService
{
    public function markPaid(int $orderId): void
    {
        // Late static binding is resolved when the closure is created
        $fn = static::logPayment(...);
        $fn($orderId);
    }

    protected static function logPayment(int $orderId): void
    {
        error_log("Order {$orderId} marked as paid");
    }
}

8. Performance-Aspekte gegenueber String- und Array-Callables

In reinen Mikrobenchmarks ist der Aufruf einer bereits erzeugten Closure aus First-Class-Callable-Syntax genauso schnell wie der Aufruf einer Closure aus Closure::fromCallable(), denn intern entsteht in beiden Faellen dasselbe Closure-Objekt. Der eigentliche Unterschied liegt nicht in der Ausfuehrung, sondern in der Aufloesung: Ein String- oder Array-Callable muss bei jedem Aufruf, den PHP nicht bereits zu einer Closure verdichtet hat, den Funktions- oder Methodennamen erneut ueber die interne Symboltabelle nachschlagen. Die First-Class-Callable-Syntax loest die Referenz einmalig bei der Erzeugung auf und liefert danach direkt einen Funktionszeiger.

In Schleifen mit vielen Iterationen macht sich dieser Unterschied bemerkbar, insbesondere wenn ein String-Callable innerhalb der Schleife jedes Mal neu aus einer Variablen zusammengesetzt wird, statt einmal ausserhalb erzeugt zu werden. Wird die First-Class-Callable-Referenz dagegen einmalig vor der Schleife erzeugt und danach nur noch aufgerufen, entfaellt der wiederholte Namens-Lookup vollstaendig.

In der Praxis ist der messbare Effekt bei einmaligen Aufrufen vernachlaessigbar. Relevant wird er in Bibliothekscode, der Callables in Hot-Paths verwendet, etwa in Template-Engines, Serialisierern oder ORM-Hydratoren, die array_map und aehnliche Konstrukte pro Request tausendfach ausfuehren. Wer die First-Class-Callable-Syntax konsequent ausserhalb von Schleifen erzeugt, profitiert zusaetzlich von OPcache, das den erzeugenden Ausdruck nicht neu kompilieren muss.

9. Migrationsleitfaden: bestehenden Callable-Code umstellen

Der praktikabelste Einstieg in die Migration ist eine gezielte Suche nach bestehenden String- und Array-Callables, etwa per Regex nach ['`[^]]+',\s*'[^']+'\] oder ueber eine PHPStan-Regel, die veraltete Callable-Muster meldet. Sinnvoll priorisiert wird nach Hot-Paths und oeffentlichen APIs zuerst, weil dort der Nutzen von Static Analysis und IDE-Refactoring am groessten ist, waehrend selten genutzter Legacy-Code eine niedrigere Prioritaet erhaelt.

Wichtig fuer die Migrationsplanung: First-Class-Callable-Syntax ist rein additiv. Bestehende Callable-Type-Hints wie callable $handler akzeptieren weiterhin Strings, Arrays und First-Class-Callables gleichermassen, sodass die Umstellung Datei fuer Datei erfolgen kann, ohne die oeffentliche Signatur einer Funktion zu veraendern. Eine Einschraenkung bleibt: Ist der Methodenname selbst erst zur Laufzeit aus einer Variablen bekannt, etwa bei dynamisch aufgeloesten Handlern, laesst sich First-Class-Callable-Syntax nicht anwenden, weil der Name zum Zeitpunkt des Parsens feststehen muss.

<?php

declare(strict_types=1);

final class LegacyReportBuilder
{
    // BEFORE: string and array callables scattered across the codebase
    public function buildLegacy(array $rows): array
    {
        $rows = array_map('trim', $rows);
        $rows = array_filter($rows, [$this, 'isValidRow']);
        usort($rows, ['LegacyReportBuilder', 'compareRows']);

        return $rows;
    }

    // AFTER: first-class callable syntax, statically verifiable
    public function buildModern(array $rows): array
    {
        $rows = array_map(trim(...), $rows);
        $rows = array_filter($rows, $this->isValidRow(...));
        usort($rows, self::compareRows(...));

        return $rows;
    }

    private function isValidRow(string $row): bool
    {
        return $row !== '';
    }

    private static function compareRows(string $a, string $b): int
    {
        return strcmp($a, $b);
    }
}

10. Zusammenfassung

Die First-Class-Callable-Syntax loest ein Problem, das seit den ersten PHP-Versionen bestand: Methodenreferenzen als opake Strings oder Arrays, die weder vom Parser noch von der IDE zuverlaessig geprueft werden konnten. Mit funcName(...), $obj->methode(...) und Klasse::methode(...) werden diese Referenzen zu echten Ausdruecken, die PHPStan, Psalm und PhpStorm wie normale Aufrufe behandeln. Tippfehler, falsche Sichtbarkeit und gebrochene Rename-Refactorings werden dadurch bereits beim Build sichtbar, nicht erst zur Laufzeit in Produktion.

Der groesste Hebel entsteht durch konsequente Anwendung ueber die gesamte Codebasis hinweg, insbesondere in Funktionen hoeherer Ordnung wie array_map, array_filter und usort. Da die Syntax rein additiv ist und bestehende Callable-Type-Hints unveraendert akzeptiert, laesst sich die Migration risikoarm Datei fuer Datei durchfuehren, ohne eine grosse Breaking-Change-Aktion planen zu muessen.

11. FAQ: First-Class-Callable-Syntax in PHP