PHP bricht Abwärtskompatibilität

Laut der aktuellen Timeline des PHP-Projektes soll PHP 7 noch in diesem Jahr erscheinen. Die Versionsnummer 6 wird dabei aus guten Gründen übersprungen.

Wie im Rahmen eines neuen Major-Releases zu erwarten ist, gibt es dabei einige Brüche in der Abwärtskompatibilität (Englisch: Backwards Compatibility Breaks). Solche Brüche sind immer ein zweischneidiges Schwert: die einen erwarten sehnlichst, dass Altlasten endlich beseitigt werden, die anderen wollen, dass vorhandene Software weiterhin ohne Änderungen läuft.

Gerade das PHP-Projekt ist bekannt dafür, dass einige "Jungendsünden" aus PHP 3-Zeiten zur Wahrung der Abwärtskompatibilität auch heute noch immer von der Sprache unterstützt werden. Man hat sich nun entschieden, mit dem Erscheinen von PHP 7 einige Features, die im 5-er Versionszweig bereits als "unerwünscht" (Englisch: deprecated) gekennzeichnet worden waren, endgültig aus der Sprache zu entfernen.

Hinzu kommt, dass die Zend Engine, der kompilierende und ausführende Kern von PHP, für PHP 7 eine grundlegende Überarbeitung erfährt. In Zeiten, in denen HHVM als alternative Laufzeitumgebung mit besserer Performance und geringerem Ressourcenverbrauch wirbt, ist dies eine Notwendigkeit, will PHP nicht längerfristig seine führende Position als Programmiersprache für das Web gefährden.

Re-Engineering PHP

In PHP 7 ergeben sich aufgrund dieser Überarbeitung allerdings auch verschiedene Verhaltensänderungen bei verschachtelten Variablenzugriffen wie $$foo['bar']['baz'] oder Foo::$bar['baz'](). Die bisher erlaubte Syntax global $$foo->bar; ist in PHP 7 nicht mehr zulässig; stattdessen muss global ${$foo->bar}; geschrieben werden.

Offenbar führen Änderungen an PHP 7 in diesem Zusammenhang dazu, dass Magento 1 nicht mehr funktioniert. Man kann nun trefflich darüber streiten, ob man solche schwer lesbaren Konstrukte denn überhaupt verwenden sollte. Zudem: das Problem ist bereits bekannt und die Änderungen sind seit Juli 2014 beschlossen. Man kann daher schon heute damit beginnen, den Code schrittweise umzustellen.

PHP 5 ist im Jahr 2004 erschienen. Danach dauerte es sehr lange, bis sich diese Version im Feld ausbreitete. Die meisten PHP-Installationen liefen noch Jahre später auf der PHP-Version 4. Der Grund war damals eine Art zyklische Abhängigkeit: bekannte Projekte unterstützten PHP 4, daher wurden sie auf einer PHP 4-Plattform eingesetzt, und da dies der Fall war, sahen viele Open Source-Projekte keine Notwendigkeit dafür, die Systemanforderungen für ihre Software auf die Version 5 zu heben, geschweige denn, die neuen Features wie beispielsweise die Unterstütztung von "richtiger" Objektorientierung zu nutzen.

Erst als das PHP-Projekt ankündigte, die Weiterentwicklung von PHP 4 einzustellen, begannen viele Projekte ernsthaft, sich mit den Möglichkeiten der neuen Version auseinander zu setzen. Ein gutes Beispiel dafür ist die Verwendung der mysqli-Erweiterung anstelle der mysql-Erweiterung. Zwar ist letzere erst seit der PHP-Version 5.5 als "unerwünscht" (deprecated) markiert, allerdings gibt es mysqli bereits seit PHP 5.0 und Sun beziehungsweise Oracle machen schon seit langem deutlich, das mysqli ihre bevorzugte Schnittstelle zwischen PHP und MySQL ist.

Der PHP-Kernentwickler und Oracle-Mitarbeiter Joahnnes Schlüter schrieb bereits 2011: "Moving away from ext/mysql is not only about security but also about having access to all features of the MySQL database". Der Hintergrund ist, dass die mysql-Erweiterung auf dem technischen Stand von MySQL 3.23 ist, das bereits im Jahr 2001 veröffentlicht wurde. In PHP 7 wird die mysql-Erweiterung nicht mehr vorhanden sein.

PEAR hörte auf zu funktionieren

In den letzten Tagen ist bekannt geworden, dass die PEAR-Umgebung aktuell mit PHP 7 nicht mehr funktioniert. Das Problem hierbei ist, dass PEAR nicht-statische Methoden statisch aufruft. Dieses Verhalten ist zwar erst seit dem Erscheinen von PHP 5.6 im vergangenen Jahr als unerwünscht (deprecated) markiert, führte davor aber schon seit Jahren zu einer E_STRICT Warnung. An sich wäre das genug Zeit gewesen, den Code entsprechend anzupassen. Da der PEAR-Installer mit PHP ausgeliefert wird und es zu Problemen mit dem Testen von PHP selbst führt, wenn der PEAR-Installer nicht funktioniert, wurde diese Änderung an PHP 7 vorübergehend rückgängig gemacht. Es ist zu wünschen, dass diese Rücknahme temporär bleibt und das PEAR-Projekt seinen Code bald an PHP 7 anpasst.

Der Autoindustrie werden regelmäßig verschärfte Abgasnormen abgefordert. Man muss alte Autos dann entweder nachrüsten oder Einschränkungen bei der Benutzung hinnehmen. Auch für Gebäude werden immer wieder die Energie- und Sicherheitsstandards verschärft, was längerfristig Umbauarbeiten bedingt. Für Software gilt das Gleiche. Das Erscheinen von PHP 7 bedeutet ja weder, dass ab diesem Zeitpunkt keine produktiv einsetzbare Version von PHP 5 mehr vorhanden ist, noch dass man nicht Zeit und Arbeit darin investieren könnte, vorhandene Software an PHP 7 anzupassen.

Das PHP-Projekt handelt richtig damit, mit PHP 7 an verschiedenen Stellen die Rückwärtskompatibiliät zu brechen. Jedes Produkt, auch eine Software, hat einen Lebenszyklus und damit eine begrenzte Lebensdauer. Man kann als PHP-Benutzer nach über 10 Jahren nicht mehr erwarten, ein Major-Update der Sprache mit signifikanten Performance-Verbesserungen "for free" zu bekommen.

Über den Autor

Stefan Priebsch
Stefan Priebsch
Twitter LinkedIn Xing
Artikel teilen
PHPUnit: Migration from PEAR to PHAR FOSDEM