Von PHP und dem Bruch mit der Abwärtskompatibilität
Kommentare

Eigentlich sollte an dieser Stelle eine Meldung über einen PHP-RFC kommen, der sich mit dem Thema Uniform Variable Syntax beschäftigt. Manchmal steckt aber mehr drin, als man meint – und plötzlich stecken wir in einer Diskussion über die WTFs und die Abwärtskompatibilität von PHP. Geht es am Ende wirklich nur um die Frage „Fortschritt: Ja oder nein“?

PHP Uniform Variable Syntax: Alles begann mit dem PHP-RFC Uniform Variable Syntax von Nikita Popov. Darin geht es um die Einführung einer konsistenten und vollständigen Variablen-Syntax. Generell ist die Variablen-Syntax eines der großen WTFs, die vor allem Neueinsteiger beschäftigt – eine Vereinheitlichung kann also im Prinzip nicht schaden.

Es kam also zur Abstimmung über den RFC – mit einem ziemlich eindeutigen Ergebnis: Der RFC wurde mit 30 zu einer Stimme für PHP 6 angenommen. Diese eine Gegenstimme stammt von Derick Rethans, der in seinem Blogpost No to a Uniform Variable Syntax erläutert, warum er gegen einen RFC gestimmt hat, bei dem ein Bruch mit der Abwärtskompatibilität billigend in Kauf genommen wird.

Unlike keyword additions, or functions and/or settings being removed, this change in semantics is probably one of the worst BC breaks you can imagine. You can’t really write a scanner for it, as the code could already have been converted. A tiny change like this however, can create very hard to debug issues within existing code. And this is exactly why people whine that PHP breaks BC and does not care about its users.

PHP und die Abwärtskompatibilität

In angesprochenem Blogpost entstand nun eine angeregte Diskussion über das Für und Wider des RFCs – und über den Bruch mit der Abwärtskompatibilität im Allgemeinen. Einer der Befürworter des RFC – Daniel Lowrey, der schon seit längerem im PHP Core aktiv ist und spätestens seit seinen Beiträgen zu PHP 5.6 einer breiteren Öffentlichkeit bekannt wurde – formuliert es auf den Punkt gebracht in etwa so:

Das Problem ist nun, dass die WTF-Rate in PHP nicht gerade gering ist. Wenn man die Codebasis aufräumen und vereinheitlichen möchte, werden sich Brüche mit der Abwärtskompatibilität nicht vermeiden lassen. Darüber hinaus heißt es im RFC:

As these changes only apply to some very rarely used syntax, the breakage seems acceptable for PHP 6.

Laut Nikita Popov dürften sich die Probleme also in Grenzen halten.

BC Break – The Dark Side

So unbedeutend wir Popov es andeutet, ist der Bruch mit der Abwärtskompatibilität allerdings nicht – der Meinung sind gleich einige der Kommentatoren im Blogpost und auf Twitter. Darüber hinaus besteht allerdings noch ein ganz anderes Problem.

PHP 5 feiert dieses Jahr seinen zehnten Geburtstag. Wenn wir zurückblicken, dann dürften sich viele daran erinnern, dass der Umstieg von PHP 4 auf PHP 5 ein – wohlwollend formuliert – zäher Vorgang war, der in einigen Bereichen heute noch nicht abgeschlossen ist. Dennoch setzen heute viele Unternehmen mit großen Projekten auf PHP 5 – ein Bruch mit der Abwärtskompatibilität könnte schnell dazu führen, dass sich PHP in der Python-3-Situation wiederfindet.

Dort war es so, dass mit dem Release von Version 3 der Sprache ebenfalls BC Breaks eingeführt wurden – und selbst Jahre danach liegt Python 2 in der Usage-Statistik noch deutlich vor der aktuellen Version.

Die Leiden des Ökosystems

Johannes sieht in den Kommentaren des oben erwähnten Blogposts allerdings noch ganz andere Probleme durch den Bruch auftreten – und die betreffen weit mehr als PHP-Entwickler:

Even for a new major version being able to break BC doesn’t mean it’s good. Changing BC adds costs to everybody in the environment. Developers having to review the code, IDE developers, tool developers, …

Ein dem RFC nach eher kleinerer BC Break hätte also enorme Auswirkungen auf das komplette Ökosystem. Anbieter der bei Entwicklern beliebten IDEs müssten ihre Tools überarbeiten (und dabei im besten Fall natürlich sowohl den Vorgänger als auch die aktuelle PHP-Version berücksichtigen) und das Bug Hunting bei großen Projekten verkäme zu einem nicht zu unterschätzenden Kostenfaktor.

Yes … No … Maybe?

Befindet sich PHP aktuell auf einem Scheideweg? Dabei muss man natürlich die Frage stellen, wo die Reise in Zukunft hingehen soll.

Die Performance der Sprache steigert sich mit jedem Major Release – auch ohne Brüche mit der Abwärtskompatibilität, was vielen Entwicklern und Projekten entgegenkommt.

Auf der anderen Seite wird bereits an der neuen Generation von PHP entwickelt – und PHPNG soll in einigen Bereichen sogar der HHVM eine ernste Konkurrenz in Sachen Performance sein. Sollte man diese Gelegenheit nicht nutzen, ein für alle mal mit den WTFs aufzuräumen?

Uns interessiert eure Meinung zu dem Thema: Sollte das PHP Core Team BC Breaks in Kauf nehmen, um die Sprache voranzubringen? Oder ist die Sprache gut, so wie sie ist, und bietet genügend Investitionssicherheit für alle?

Aufmacherbild: Timeline concept: Red Break Time on grunge textured concrete wall background von Shutterstock / Urheberrecht: Maksim Kabakou

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -