Compile-time-only Generics: der realistische PHP-Kompromiss

Wer kennt es nicht: Du änderst in einem PHP-Projekt nur eine kleine Ecke, alles sieht sauber aus, und zwei Tage später kracht es an einer Stelle, die vorher niemand auf dem Zettel hatte.

Genau da kommt die Frage aus dem Teamalltag auf den Tisch. Wenn volle Laufzeit-Generics in PHP teuer sind, wie bekommen wir trotzdem mehr Typklarheit, ohne den Betrieb auszubremsen?

Für mich ist die Antwort ein nüchterner Kompromiss: mehr Typgarantien in Compile- und Analysephase, weniger Last zur Laufzeit.

Warum dieser Mittelweg sinnvoll ist

Ich will in Projekten zwei Dinge gleichzeitig erreichen. Mehr Sicherheit beim Entwickeln und stabile Performance im Betrieb.

Volle Laufzeit-Generics würden sehr viel Ausdrucksstärke bringen, aber in einer dynamischen Sprache auch erhebliche Kosten verursachen. Ein compile-time-orientierter Ansatz verschiebt den Fokus dorthin, wo Typfragen am günstigsten geklärt werden können, also vor dem Hot Path zur Laufzeit.

Das ist nicht maximal elegant. Es ist aber im Alltag oft maximal vernünftig.

Was "compile-time-only" praktisch bedeutet

Für mich heißt das nicht, dass plötzlich alle Typprobleme verschwinden. Es heißt, dass bestimmte generische Verträge früher und strenger geprüft werden, statt später und teurer.

Typische Wirkung im Team:

• falsche Typannahmen fallen früher auf,
• Architekturgrenzen werden expliziter,
• Reviews werden klarer,
• Refactorings werden planbarer.

Der große Vorteil liegt nicht in Magie, sondern im Prüfzeitpunkt.

Wo ich den größten Nutzen sehe

Ich sehe besonders viel Hebel bei abstrakten Verträgen. Also dort, wo Interfaces und abstrakte Klassen festlegen, welche Typen ein Modul akzeptiert und zurückgibt.

Genau an diesen Stellen entstehen in größeren Codebasen häufig die teuersten Missverständnisse. Wenn ich sie früh auflöse, spare ich später Incident-Zeit, Debugging und Nacharbeit.

Was dieser Ansatz nicht löst

Ich erwarte davon keine vollständige Generic-Utopie. Bestimmte dynamische Laufzeitfälle bleiben anspruchsvoll, besonders dort, wo viele Typvarianten zur Laufzeit kombiniert werden.

Das ist für mich kein Nachteil, sondern ehrliche Erwartungssteuerung. Ich bekomme einen großen Teil des Nutzens, ohne den Kern der Sprache in einen Performancekonflikt zu treiben.

Mein pragmatisches Vorgehen im Projektalltag

Ich setze deshalb auf eine gestufte Strategie.

1) Verträge zuerst schärfen

Ich starte bei Interfaces, Repositories und Service-Grenzen. Dort definiere ich klar, welche Typen erlaubt sind und welche nicht.

2) Analyse in CI verbindlich machen

PHPStan oder Psalm laufen bei mir nicht optional, sondern als verbindliches Gate. Ohne grüne statische Analyse geht kein Merge durch.

3) Komplexität an den Rändern halten

Im Domänenkern halte ich Typmodelle bewusst einfach. Komplexe Varianten behandle ich an Integrationsgrenzen, wo sie kontrolliert und testbar bleiben.

4) Schrittweise modernisieren statt Big Bang

Ich migriere bestehende Systeme in kleinen, messbaren Schritten. So bleibt Delivery stabil, während die Typsicherheit wächst.

Ein kleines Bild dazu

Ich vergleiche das gern mit einer Qualitätsprüfung in der Werkstatt. Wenn ich Maße und Material schon vor dem Einbau prüfe, verhindere ich teure Rückbauten auf der Baustelle.

Compile-time-orientierte Typprüfung ist genau das. Fehler möglichst früh finden, damit sie im Betrieb nicht teuer werden.

Fazit

Für mich ist "compile-time-only Generics" kein Notbehelf. Es ist ein realistischer Weg für produktive PHP-Teams.

Ich bekomme bessere Typverträge, frühere Fehlererkennung und stabilere Refactorings, ohne die Laufzeit mit maximaler Typdynamik zu überladen. Das ist genau die Art Kompromiss, die in produktiven Teams funktioniert.

Wenn du magst, kannst du mit dem Projekt-Check prüfen, wie robust eure Architektur-, Test- und Typsicherheitsbasis aktuell ist.