Neue Version des PHP: Hypertext Preprocessor PHP 8 – und was die Zukunft bringt

Autor / Redakteur: Filipe Martins und Anna Kobylinska / Stephan Augsten

Endlich hat die finale Fassung von PHP 8 das Licht der Welt erblickt, praktisch eine Punktlandung fünf Jahre nach PHP 7. Grund genug, um die neuen Features auf die Probefahrt zu nehmen. Die Liste prominenter neuer Features ist lang. Braucht jetzt Altlasten-Code zwingend ein Refactoring?

Firma zum Thema

PHP 8 hat den Startblock verlassen und bläst zur Aufholjagd in der Entwickler-Community.
PHP 8 hat den Startblock verlassen und bläst zur Aufholjagd in der Entwickler-Community.
(Bild: Markus Spiske / Unsplash)

PHP zählt nach wie vor zu den beliebtesten Web-Sprachen. Laut Angaben von W3Techs läuft der PHP-Interpreter auf 78,9 Prozent aller Webseiten, die ihre serverseitige Programmiersprache zu erkennen geben. Web-Anwendungen wie WordPress, MediaWiki (Wikipedia), Drupal und Joomla setzen alle PHP voraus.

Seit der letzten großen PHP-Version, die bekannterweise die Glückszahl Sieben trug und im Jahre 2015 das Licht der Welt erblickte, fand in der Welt der Softwareentwicklung ein Paradigmenwechsel nach dem anderen statt.

DevOps nahm an Fahrt auf; agile Softwareentwicklung ist dank der kurzen Release-Zyklen nicht nur möglich, sondern mittlerweile das Gebot der Stunde. Cloud-native verteilte Anwendungen laufen als Microservices in Containern oder als Funktionscode in einer Serverless-Bereitstellung. Elastische Skalierbarkeit ist in der Cloud gang und gäbe.

Für die PHP-Gemeinde war es deshalb höchste Eisenbahn, die beliebte Skriptsprache auf die Höhe der Zeit zu bringen. Die große Frage lautet: Hat es denn geklappt?

Neue Features umfassen:

  • Unionstypen: Diese Sammlungen von zwei oder mehr Typen verhelfen der dynamisch typisierten Sprache zu mehr Disziplin; sie können übrigens NULL-fähig sein.
  • JIT in PHP: PHPs eigener Just-in-time-Compiler verspricht Leistungsverbesserungen.
  • der nullsafe-Operator: Da der Null-Koaleszenz-Operator bei Methodenaufrufen nicht funktioniert, waren bisher Zwischenprüfungen oder optionale Helfer aus diversen Frameworks vonnöten; der neue nullsafe-Operator in PHP 8 ?-> kann ein Null-Koaleszenz-ähnliches Verhalten für Methoden sicherstellen.benannte Argumente: Durch die Angabe des Wertnamen lassen sich Werte an eine Funktion übergeben und optionale Parameter überspringen.
  • Attribute (in anderen Sprachen: annotations): In PHP 8 lassen sich jetzt Metadaten zu Klassen, Methoden, Variablen und anderen Sprachkonstrukten hinzufügen; das manuelle Analysieren von docblocks-Kommentaren entfällt.
  • der match-Ausdruck: Der „große Bruder“ des switch-Ausdrucks kann Werte zurückgeben, erfordert keine break-Anweisungen, kann Bedingungen kombinieren, verwendet strenge Typvergleiche und verursacht keinen Typzwang.
  • Beförderung von Konstruktor-Eigenschaften (engl.: constructor property promotion): Dank neuer syntaktischer Zusätze lassen sich Wertobjekte (value objects) oder Datentransferobjekte (data transfer object) effizienter erstellen.
  • Rückgabetyp static: Lange ersehnt ist der Rückgabetyp jetzt endlich ganz legal verwendbar;
  • Rückgabetyp mixed: Dieser neue Rückgabetyp ist im Übrigen bereits NULL-fähig;
  • throw: ist jetzt ein Ausdruck, nicht eine Anweisung;
  • Schluss mit Vererbungsprüfungen für private Methoden: Private Methoden unterliegen nicht mehr denselben Methodensignaturregeln wie geschützte und öffentliche Methoden; die Nutzung von final private function löst jetzt eine Warnung aus.
  • WeakMaps: Die WeakMap-Implementierung in PHP 8 ermöglicht es, Objekte zu „kartografieren“, ohne die Garbage Collection der zugehörigen Schlüssel zu beeinträchtigen.
  • Objektimplementierung von PhpToken::getAll(): Die Einführung der neuen Klasse PhpToken ermöglicht die Rückgabe eines Arrays von Objekten mittels PhpToken::getAll(), was die Anforderungen an den Arbeitsspeicher senkt und zur verbesserten Lesbarkeit beiträgt.
  • Typ-Anmerkungen: Interne Funktionen und Methoden verfügen jetzt über vollständige Typ-Informationen
  • zahlreiche Syntax-Verbesserungen und vieles andere.

Zu den etwas ungewöhnlichen Features in PHP 8 zählen Weak Maps. Eine Weak Map beinhaltet Verweise auf Objekte (ähnlich wie bei SplObjectStorage), ohne die Garbage-Collection der Schlüssel zu verhindern. Wenn ein Objektschlüssel von der Garbage-Collection erfasst wird, verschwindet er einfach aus der Map.

PHP hatte bereits in der Version 7.4 eine erstklassige Unterstützung für schwache Referenzen eingeführt. „Rohe“ schwache Referenzen sind jedoch an und für sich nur von begrenztem Nutzen. In der Praxis greifen Entwickler bevorzugt auf Weak Maps zurück. Mangels einer Möglichkeit zum Registrieren eines Zerstörungsrückrufs ist die Umsetzung von effizienten Weak Maps auf dem Unterbau von schwachen Referenzen rein unmöglich.

Der allgemeine Anwendungsfall für Weak Maps besteht darin, einzelnen Objektinstanzen Daten zuzuordnen, ohne sie zu zwingen, „am Leben zu bleiben“, was ja bei langlaufenden Prozessen effektiv Speicher verschwenden würde. Eine Weak Map lässt sich beispielsweise nutzen, um das Ergebnis einer Berechnung zu speichern.

ORMs (Object Relational Mapper) implementieren typischerweise Caches für Verweise auf Klassen von Entitäten mit dem Ziel, die Leistung zu verbessern. Solange der Cache einen Verweis auf diese Entitätsobjekte beinhaltet, lassen sie sich nicht in einer Garbage Collection entsorgen, auch wenn sonst keine Referenzen darauf noch bestehen bleiben sollten.

Verwendet diese Cache-Ebene Weak Maps anstelle von schwachen Referenzen, entsorgt PHP 8 die betreffenden Objekte via Garbage Collection – unter der Voraussetzung, dass sie nicht noch an anderer Stelle referenziert werden. Weak Maps können daher einen besseren, ressourcenschonenderen Weg bieten, mit diesen Objekten umzugehen; insbesondere im Fall von ORMs, die viele hunderte, wenn nicht gar tausende von Entitäten innerhalb einer Anfrage verarbeiten können.

Weak Maps sehen etwa so aus (ein Beispiel aus dem RFC):

class Foo {
   private WeakMap $cache;
   public function getSomethingWithCaching(object $obj): object
   {
      return $this->cache[$obj]
      ??= $this->computeSomethingExpensive($obj);
   }
}

Gemischte Gefühle

Manche nennen es ein notwendiges Übel, anderen bereiten gemischte Typen auch gemischte Gefühle. Dennoch gibt es einen wirklich guten Grund dafür: Ein fehlender Typ kann in PHP eine Menge bedeuten:

  • ein Feature liefert nichts oder null zurück,
  • die Rückgabe kann einen von vielen verschiedenen Typen beinhalten,
  • es ist ein Typ zu erwarten, der in PHP nicht gehintet werden kann.

Aus diesem Grunde ist die Einführung von gemischten Typen (mixed types) eigentlich eine clevere Idee. In PHP 8 läuft es auf einen dieser Typen hinaus:

  • float
  • null
  • object
  • resource
  • string
  • array
  • bool
  • callable
  • int

Es ist wichtig darauf zu achten, dass ein gemischter Typ auch als ein Parameter oder als Eigenschaften-Typ (property type) vorkommen kann, nicht nur als ein Rückgabetyp. Doch jetzt wird es brenzlig. Ein gemischter Typ kann durchaus auch null sein, d.h. einen gemischten Typ darf man keinesfalls als „nullable“ betrachten. Wer es dennoch wagt:

function bar(): ?mixed {}

… löst einen fatalen Fehler aus. Mixed Types sind insofern nicht nullable, da null bereits ein fester Bestandteil der Mixed-Type-Spezifikation ist.

Der Abschied von Microsofts offiziellen PHP-Builds für Windows

Bisher hat Microsoft eigene Builds von PHP für Windows erzeugt und für diese ganz auf Azure offiziell Support geboten. Damit ist jetzt Schluss. Microsofts offizielle PHP-Builds für Windows haben ein definiertes EoL:

  • PHP 7.2 lief bereits am 30. November 2020 aus,
  • PHP 7.3 hat das Verfallsdatum 6. Dezember 2021,
  • PHP 7.4 behält seine Support-Privilegien bis zum 28. Nov. 2022 bei.

Der Azure App Service, Microsofts vollständig verwalteter Dienst zur Bereitstellung von Web-Anwendungen, ist seit Mitte Juli 2019 nicht nur exklusiv für Windows, sondern auch für Linux verfügbar. Wer PHP 8 als gemanagten Service in der Azure-Cloud nutzen möchte, soll nun gefälligst auf Linux Server zurückgreifen.

Microsoft selbst hat ja auch keinerlei Berührungsängste, Workloads in Azure überwiegend auf Linux Server laufen zu lassen; zurzeit sind es ca. 60 Prozent aller Workloads. Die Unterstützung von PHP unter Windows ist von der Abschaffung von PHP in Azure App Service nicht betroffen.

Die Achterbahn in die Zukunft

In der aktuellen JetBrains-Umfrage „The State of Developer Ecosystem 2020“ konnte PHP im Hinblick auf seine Popularität während der vorangegangenen 12 Monate den begehrten neunten Platz einheimsen – zwar weit abgeschlagen hinter JavaScript/TypeScript und Python, aber entschlossen vor den Neuzugängen Go, Kotlin, Dart und Swift. PHP wäre im Rang beinahe mit C++ gleichgezogen.

Auf die Resultate der Umfrage färben die Präferenzen der befragten Zielgruppe ab. Zum Vergleich: In der jährlichen Octoverse-Umfrage von Github kam PHP zuletzt auf Platz vier an. Die JetBrains-Umfrage ist wie erwartet JetBrains-technologielastig; sie verzerrt das Bild zugunsten jener Coder, die mit JetBrains-Tools und Sprachen wie Kotlin arbeiten.

Das ein oder andere Körnchen Wahrheit ist sicherlich trotzdem zu finden, besonders wenn man etwas in die Zukunft schaut. Für satte 15 Prozent der von JetBrains befragten Coder ist PHP die primäre Entwicklungssprache. In dieser Kategorie nimmt PHP den sechsten Platz ein, hinter JavaScript (39 Prozent aller befragten Entwickler), Java (37 Prozent), Python (31 Prozent), HTML/CSS (22 Prozent) und SQL (17 Prozent).

Die Mehrheit jener Coder, die PHP als ihre primäre Entwicklungssprache nannten, plant allerdings, in Zukunft auch andere Sprachen heranzuziehen: zu 14 Prozent Go, zu 13 Prozent Python und zu je elf Prozent Kotlin und TypeScript. Weniger als jeder zweite (43 Prozent) hat derlei keine Pläne geschmiedet. Unter den Entwicklern der übrigen neun führenden primären Entwicklungssprachen wollte Anfang des Jahres 2020 so gut wie niemand auf PHP umsatteln.

Ist PHP schon auf dem Abstellgleis?

So ist es auch kein Wunder, dass PHP im Hinblick auf das prognostizierte Wachstum das Schlusslicht unter den zehn meistgenutzten Sprachen des Webs bildet; noch schlechter schneidet nur noch das Duo aus HTML/CSS ab. Die Zukunft sieht damit etwas düster aus.

Inzwischen wächst der Neuzugang Go außer Rand und Band. Googles von Grund auf neu konzipierte quelloffene Programmiersprache für verteilte Web-Anwendungen dürfte den Internet-Veteran PHP bald von seiner jetzigen Position im Ranking der meistgenutzten Sprachen um einen Platz nach unten schubsen. Je weniger Entwickler sich mit PHP auskennen, umso weniger Anwendungen werden in dieser schon etwas angestaubten Skriptsprache entstehen,

Die Google-Trends-Suche nach PHP zeigt die Sprache seit Einführung der Suchmaschine im Jahre 2004 erbarmungslos auf Talfahrt. Zum Teil lässt sich das Phänomen sicherlich auf die Tatsache zurückführen, dass die Gemeinde viele Unzulänglichkeiten der Sprache im Laufe der Jahrzehnte ausmerzen konnte, so dass sich die eine oder andere Suche nach PHP-Bugs erübrigt oder ohne Google bewerkstelligen lässt.

Fakt ist nämlich auch, dass letztlich keine der PHP-Alternativen die Anzahl der Google-Suchanfragen nach PHP übertreffen konnte. Vielen ist es klar: Für die PHP-Gemeinde steht mit dem Erfolg der Version 8 eine ganze Menge auf dem Spiel. PHP ist noch weit davon entfernt, den Geist aufzugeben. Mit dem Update auf die Version 8 lebt die Sprache vielmehr auf. Auf das nächste große Update sollte die Gemeinde jedoch nicht schon wieder ein halbes Jahrzehnt warten müssen.

Tipp: Ein quelloffenes Werkzeug namens Rector meistert das Refactoring von altem PHP-Code und kann die Umstellung bestehender Web-Anwendungen auf PHP 8 wesentlich beschleunigen.

Fazit

„Eine gute Lösung sollte bei existierenden Technologien Anleihen machen“, glaubt bekannterweise PHPs Erfinder Rasmus Lerdorf. PHP 8 folgt stolz diesem Grundsatz, indem die Sprache bewährte Ansätze ihrer Mitbewerber implementiert. Bei den zahlreichen Verbesserungen haben die ausdrücklichen Wünsche der Nutzergemeinde eine überragende Rolle gespielt. Die Qualität und somit auch die Leistung des resultierenden Codes dürfte um Längen zulegen.

(ID:47008241)