Da zwischen
Viele, die heute mit der Skriptsprache PHP ihre Webseiten dynamisch erzeugen, bedienen sich immer noch der alten Version 4, obwohl PHP 5 mehr bietet. Und bis PHP 6 ist es nicht mehr lange hin. Migrieren geht ĂĽber studieren ...
- Stefan Priebsch
PHP 4 geht, PHP 6 kommt. Am 13. Juli dieses Jahres haben die Verantwortlichen auf der Website des PHP-Projektes (siehe den Kasten „Onlineressourcen“) offiziell verkündet, dass sie die Weiterentwicklung und Pflege von PHP 4 zum 31. Dezember 2007 einstellen. Kritische Bugfixes soll es nur bis zum 8. August 2008 geben. Mit dem Beginn der Olympischen Spiele in Peking sind die Benutzer von PHP 4 deshalb endgültig zur Migration gezwungen oder auf sich allein gestellt.
Laut dem Tiobe-Index im Juli 2007 liegt PHP auf Platz 5 der populärsten Programmiersprachen (siehe Link im Kasten). Der Index ist allerdings mit etwas Vorsicht zu genießen. Die Erfassungsgrundlage ist nicht etwa der Umfang von geschriebenem oder ausgeliefertem Code, sondern eine Suchmaschinenrecherche. Sie bewertet, wie häufig der Name einer bestimmten Programmiersprache in Suchergebnissen auftaucht. Zwar ist das ein Indikator für die Popularität einer Sprache, letztlich bedeutet dies jedoch lediglich, wie viel über eine bestimmte Programmiersprache geschrieben wird.
Nexen, eine französische Website, erstellt laufend Statistiken über die PHP-Nutzung im Internet. Danach lief im Juni 2007 auf rund 33 % aller Websites PHP. Dies bedeutet nicht unbedingt, dass alle diese Websites in PHP erstellt sind, sondern dass PHP für die jeweiligen Domains aktiviert ist. Auf der anderen Seite geben viele Produktionsserver im Internet aus Sicherheitsgründen keine Auskunft darüber, welche Software dort installiert ist. Eventuelle PHP-Installation auf diesen Servern kann die Statistik deshalb nicht erfassen. Zudem bleiben PHP-Installationen innerhalb lokaler Netze ebenfalls außen vor. Gerade hier dürften sich sowohl in Form von Intranet-Servern, Entwicklungs- und Testsystemen eine erhebliche Anzahl PHP-Systeme tummeln.
Laut Nexen liefen im Juni 2007 mehr als drei Viertel der PHP-Domains im Internet noch mit PHP 4. Wenn man bedenkt, dass PHP 5 im Juli 2004 veröffentlicht wurde, kann man getrost von einer recht gemächlichen Adaption sprechen. Dafür gibt es verschiedene Gründe. Ein wesentlicher ist sicherlich die Tatsache, dass weit verbreitete PHP-Anwendungen wie phpMyAdmin, die Bildergalerie Coppermine, die Blog-Programme Wordpress oder Serendipity, Content Management-Systeme wie Drupal, ezPublish und Typo3 oder Mediawiki, die Anwendung hinter Wikipedia, lediglich PHP 4 voraussetzen. Mit Ausnahme von ezPublish sollten diese Programme allerdings unter PHP 5 ebenfalls laufen.
PHP 5: Zögerliche Akzeptanz
Auch die PHP-Kernentwickler haben ihr Scherflein zur langsamen Adoption von PHP 5 beigetragen, indem sie über drei Jahre beide Versionen parallel weiterentwickelt und gepflegt haben. Letztlich reduziert sich der Vorteil von PHP 5 aus Anwendersicht darauf, dass die Version objektorientierte Programmierung unterstützt. Zwar gibt es in PHP 4 schon ein rudimentäres Klassenkonzept, aber da dort Objekte standardmäßig nicht per Referenz übergeben werden, sondern jeweils eine Kopie erzeugt wird, ist der Programmierer gezwungen, seinen Code mit reichlich &-Zeichen zu würzen, um das Übergeben als Referenz jeweils explizit zu erzwingen. Wehe dem, der wegen eines vergessenen Kaufmannsunds versehtlich ein Objekt kopiert und sich später wundert, warum seine Änderungen an einem Objekt nicht sichtbar werden (vor allem deshalb, weil er jetzt zwei unabhängige Instanzen dieses Objektes im Speicher hat).
Ein Teufelskreis: PHP 4 ist installiert, und getreu dem Prinzip „Never touch a running system“ bleibt das bis auf Weiteres so. Viele PHP-Programmierer weigern sich - selbst in größeren Projekten - noch immer standhaft, Objektorientierung einzusetzen. Nun sind objektorientierte Programme bekanntlich zwar nicht mächtiger als prozedurale, aber einfacher erweiterbar und wartungsfreundlicher. Mit ein paar Tricks lässt sich prozeduraler PHP-Code ebenfalls recht modular gestalten, beispielsweise, indem man dynamisch selektiv Code nachlädt. Die Entwickler von Drupal, einem in PHP geschriebenen CMS und Framework beispielsweise haben sich bewusst gegen Objektorientierung entschieden (siehe „Onlineressourcen“), nicht zuletzt, weil PHP 4 diese nur unzulänglich unterstützt.
Da nun die Nutzerbasis von PHP 4 noch immer groß ist, werden viele Programme so geschrieben, dass sie zu dieser Version kompatibel sind. Man möchte nicht die große Nutzerbasis verschrecken, die mit günstigem Shared Hosting leben muss und dort vermeintlich kein PHP 5 zur Verfügung hat. Tatsächlich ist es aber so, dass viele Hosting-Firmen beide Versionen anbieten, standardmäßig aber PHP 4 aktiviert ist, damit die älteren Programme noch ohne Stolpersteine laufen. Und da die wichtigen Programme auf PHP 4 laufen - warum sollte man als Benutzer auf PHP 5 migrieren? Hier schließt sich der Teufelskreis, der die langsame Verbreitung von PHP 5 erklärt.
Einige bekannte PHP-Programme allerdings haben stets auf Objektorientierung und PHP 5 gesetzt und so über die Jahre sicherlich dazu beigetragen, dass zumindest Entwickler begonnen haben, mit dieser Version zu arbeiten, selbst wenn sie ihre Software noch PHP 4-kompatibel programmiert haben. Als Beispiele seien hier PHPUnit, das vermutlich meistgenutzte Test-Framework für PHP, phing, ein auf dem Apache-Projekt Ant basierendes Werkzeug zur Build-Automation oder Propel, ein von Apache-Torque inspirierter objektrelationaler Mapper, genannnt. Diese Programme zeigen recht eindrucksvoll, dass sich die objektorientierte Programmierung mit PHP nicht mehr hinter Java verstecken muss. Allerdings hat die Tatsache, dass die genannten Profi-Werkzeuge nur für PHP 5 verfügbar sind, zwangsläufig zu einer nicht unbedingt vorteilhaften Spaltung der PHP-User-Gemeinde in die professioneller arbeitenden PHP 5-Nutzer und die eher nostalgisch orientierten PHP 4-Nutzer geführt.
Nicht drei Versionen pflegen
Sicher ist, dass das Team der Kernentwickler spätestens mit Erscheinen von PHP 6 nicht mehr in der Lage sein wird, über einen längeren Zeitraum drei Major-Versionen der Skriptsprache zu pflegen. Schon jetzt ging die Pflege von PHP 4 deutlich zu Lasten der neuen Version 6, deren Entwicklung langsamer als gewollt voranschreitet. War das „Killer“-Feature von PHP 5 die Unterstützung objektorientierter Programmierung, dürfte das von PHP 6 die Unicode-Unterstützung sein (siehe Kasten). Allerdings verhält es sich hier ähnlich wie mit der Objektorientierung: Viele Entwickler brauchen Unicode nicht. Wer bisher mit ISO-8859-x-Zeichen ausgekommen ist, um hauptsächlich den englischsprachigen Markt zu bedienen, hat kaum Bedarf an Unicode.
Da Unicode mehr Speicherplatz benötigt als ASCII-Zeichen und zur Laufzeit mehr Typkonvertierungen erforderlich sind, wird PHP 6 langsamer als PHP 5 sein. Man spricht zurzeit von etwa 20 % Performance-Einbuße. Das ist ein schlechtes Verkaufsargument für die kommende Version, vor allem für Nutzer, die selbst keine Unicode-Unterstützung benötigen. Freilich dürfte sich die Performance von PHP 6 mit der Zeit verbessern. Bei PHP 5 hat es bis zur Version 5.1 gedauert, bis die Performance von PHP 4 erreicht und sogar überschritten war (siehe die Links zur Performance).
Ob PHP wirklich Unicode braucht, wird immer wieder hitzig diskutiert. Einige Kernentwickler drohten gar mit einem Fork, der Abspaltung einer Nicht-Unicode-Version von PHP. Natürlich ist allen Beteiligten klar, dass eine derartige Spaltung dem PHP-Projekt und seinem Ansehen massiv schaden könnte, deshalb ist ein solcher Fork in der Realität wohl eher unwahrscheinlich.
Wer braucht denn nun Unicode in PHP? Der norwegische CMS-Hersteller ez Systems, eins der Schwergewichte in der PHP-Szene, äugt mit der neuen Version des CMS ezPublish auf den internationalen und besonders auf den asiatischen Markt. Ohne Unicode ist da freilich nicht viel zu holen. Ebenso macht sich Yahoo, die massiv PHP einsetzen und einige PHP-Größen wie Rasmus Lerdorf oder Sara Golemon auf der Gehaltsliste haben, für die Unicode-Unterstützung stark. Man plant offenbar, die zahlreichen internationalen Plattformen mit Unicode-basiertem PHP vereinheitlichen zu können, um zukünftig erheblich Entwicklungs- und Wartungskosten zu sparen.
Die Vermutung, diese Firmen wĂĽrden gegen den Willen der anderen PHP-Kernentwickler und der Community die Unicode-UnterstĂĽtzung in PHP erkaufen, greift etwas zu kurz, geht andererseits aber nicht ganz an der Wahrheit vorbei. PHP ist eben eine quelloffene Sprache, in die die Kernentwickler Features einbauen, die sie fĂĽr ihre Projekte brauchen - oder fĂĽr die ihr Arbeitgeber beziehungsweise ein Sponsor sie bezahlt.
Aufruf an alle: gophp5
Eine Gruppe von PHP-Anwendungsentwicklern hat in diesem Sommer das Dilemma der verschleppten Migration von PHP 4 auf PHP 5 erkannt. Unabhängig von der Ankündigung der Kernentwickler, den Support der 4er-Version einzustellen, haben sie die Initiative gophp5 ins Leben gerufen. Entwickler von PHP-Software sind aufgerufen, sich der Initiative anzuschließen und ab dem 5. Februar 2008 für neue Releases ihrer Software PHP 5.2.0 als Mindestvoraussetzung zur Installation festzulegen. Auch Hosting-Firmen können sich der Initiative anschließen, wenn sie zu diesem Zeitpunkt ein Hosting-Paket anbieten, das mindestens mit PHP 5.2.0 ausgestattet ist.
Mittlerweile haben sich mit Doctrine, Drupal, osCommerce, phpMyAdmin, Symfony, Typo3 sowie dem PEAR-Projekt, einer Sammlung freier Komponenten für PHP ähnlich dem CPAN für Perl, schon einige bekannte und wichtige Projekte der Initiative angeschlossen. Es bleibt zu hoffen, dass durch die vereinten Anstrengungen der Kernentwickler, der gophp5-Initiative und zahlreicher weiterer Entwickler im nächsten Jahr die lange verzögerte Migration von Version 4 auf 5 auf breiter Front stattfindet.
Doch nach der Migration ist vor der Migration. PHP 6 sollte 2008 fertig sein. Nicht viel später dürfte die Frage aufkommen, wie lange man Version 5 noch weiterentwickeln und unterstützen kann, und wie schnell die Benutzer auf PHP 6 migrieren werden. In Anbetracht der Tatsache, dass sich PHP 6 von PHP 5 wieder nur durch eine zunächst wenig beachtete Eigenschaft, die Unicode-Unterstützung, unterscheidet, scheint PHP auf dem besten Weg, seine eigene Geschichte zu wiederholen. Denn warum sollte man, nachdem man gerade mühsam auf PHP 5 migriert hat, bald darauf schon wieder eine Migration nach PHP 6 durchführen, vor allem wenn man die Unicode-Untersützung gar nicht braucht? Und sofern die gängigen und beliebten PHP-Anwendungen nicht PHP 6 explizit unterstützen, dürfte diese Version das Schicksal von PHP5 teilen und nur langsam Verbreitung finden.
Glücklicherweise hat PHP 6 kürzlich noch eine weitere interessante Eigenschaft erhalten: Namensräume. Viele Entwickler von Bibliotheken und Frameworks haben lange und sehnlichst darauf gewartet, ohne die Präfixe und langen Klassennamen zu arbeiten, mit denen man heute versucht, die Eindeutigkeit von Klassennamen sicherzustellen. Im Sinne des Fortschritts bleibt allerdings zu hoffen, dass die Namensräume nicht nach PHP 5 rückportiert werden, denn das würde den Benutzern wieder einen wichtigen Anreiz für das Upgrade auf PHP 6 nehmen.
In jedem Fall steht PHP und seiner Community eine spannende Zukunft bevor. Und die bestimmen nicht nur die Kernentwickler, sondern zu gleichen Teilen die Anwendungsentwickler und Nutzer. Open Source ist eben, was alle daraus machen.
Dipl.-Inform. Stefan Priebsch
löst seit über 20 Jahren IT-Probleme, und setzt dafür gerne freie Software und besonders PHP ein.
AuĂźerdem lesen Sie in der aktuellen Printausgabe einen Artikel zu den vier PHP-Frameworks Zend, eZ Components, Symfony und CakePHP.
