PHP 6: Alt und neuPHP 6 – ein Ausblick
Diskussion um PHP 6
PHP 6: Alt und neu
Mit PHP 5 ist den Entwicklern vor allem in Sachen Objektorientierung ein Quantensprung gelungen. Die Frage ist also, was in einer Version 6 passieren soll. Anfangs gab es dazu nur ein paar Gerüchte und viele widerstreitende Meinungen. Rasmus Lerdorf, der PHP-Erfinder, begann die Diskussionen um die neue Version im August 2005 mit einer Mail in der internen Mailingliste für PHP-Entwickler. Dabei ging es vor allem darum, einige alte Zöpfe abzuschneiden und wichtige Neuerungen in Gang zu bringen. Die schon lange geplante Unicode-Integration stand zu diesem Zeitpunkt auch schon als Aufgabe fest.
Die auf diese Mail folgende Diskussion gipfelte dann in einem Treffen der Kernentwickler in Paris im November 2005. Die hierzu von Derick Rethans verfasste Zusammenfassung ist nach wie vor in den meisten Punkten aktuell, denn dort wurden in vielen Punkten bereits Entscheidungen getroffen. Andere Fragen wie beispielsweise Namespaces für die Objektorientierung werden dagegen immer noch auf der internen Mailingliste diskutiert.
Alte Zöpfe
Die wichtigsten Vorschläge von Rasmus Lerdorf gingen dahin, einige der alten Zöpfe abzuschneiden, die PHP schon seit mehreren Versionen mit sich herumschleppt, ohne dass sich positive Effekte daraus ergeben haben. Allerdings wurden viele davon bisher noch nicht abgeschaltet, da sonst die Abwärtskompatibilität verloren geht. Für PHP 6 wurde nun auch von den übrigen Entwicklern mit entschieden, auf welche Funktionen und Konfigurationseinstellungen verzichtet werden kann.
Eine problematische Einstellung ist die php.ini-Einstellung register_globals. Sie erlaubt – wenn auf on geschaltet, unter anderem noch den Zugriff auf POST– und GET-Werte sowie Cookies per Variablenname. Heißt das Formularfeld also eingabe, steht der Wert als $eingabe zur Verfügung. Das ist aber in bestimmten Szenarien gleichzeitig ein Sicherheitsproblem. Deswegen wurden in PHP 4 zuerst die globalen Variablen $HTTP_*_VARS eingeführt, wobei das Sternchen den Ursprung des Werts angibt und dementsprechend für GET, POST et cetera steht. Diese Variablen werden in PHP 6 allerdings auch entfernt, und damit verschwindet auch die zugehörige Konfigurationseinstellung register_long_arrays aus der php.ini. Das heißt, in PHP 6 ist nur noch die superglobale Alternative $_GET beziehungsweise $_POST möglich.
Ein weiterer alter Zopf ist der safe_mode und alle zugehörigen Einstellungen. Ursprünglich wurde er eingeführt, um in Shared-Hosting-Umgebungen für Sicherheit zu Sorgen. Er überprüft, ob der Eigentümer eines Skripts auch der Eigentümer einer zu bearbeitenden Datei ist. Das ist beispielsweise ein Problem, wenn eine Datei per FTP hochgeladen wurde und der Nutzer der Datei damit der FTP-Nutzer ist, während das Skript als Webnutzer läuft. Auf den safe_mode soll dementsprechend vor allem zu Gunsten von open_basedir verzichtet werden. Mit dieser Einstellung kann der Serveradministrator den Skriptzugriff auf ein Basisverzeichnis beschränken.
Die dritte bekannte Konfigurationseinstellung ist die magic_quotes-Familie. Sie wurde eingeführt, um Nutzereingaben zu filtern. Hier wird beispielsweise einem einfachen oder doppelten Anführungszeichen, das der Nutzer per GET, POST oder Cookie übermittelt (Einstellung magic_quotes_gpc) ein Backslash vorangestellt. Das Ziel ist, sicherheitskritische Angriffe wie SQL-Injection zu vermeiden. Leider erfüllen die Konfigurationseinstellungen ihren Zweck nicht wirklich: Zum einen sind sie umgehbar, zum anderen werden die Filterungen vor dem Ausführen des Skripts angewendet und der Entwickler hat darüber keine Kontrolle. In PHP 6 sollen diese Pauschalkonfigurationen deswegen verschwinden und durch die optional einsetzbaren Eingabefilter ersetzt werden. Diese basieren auf der schon für aktuelle PHP-Versionen verfügbaren filter-PECL-Erweiterung (pecl.php.net/package/filter), die bereits seit Version 5.2 bei PHP mit dabei ist.
Bei allen drei Konfigurationseinstellungen soll in PHP 6 beim Start von PHP ein E_CORE_ERROR entstehen. Die Funktionalität selbst verschwindet komplett. Während also von PHP 4 zu PHP 5 die Migration bei der Objektorientierung etwas weh tat und tut, wird in PHP 6 die Übernahme der Uralt-Skripts schmerzhaft. Um allerdings ehrlich zu sein, diese alten Zöpfe müssten eigentlich jetzt schon abgeschnitten werden. Und auch die Entscheidung, die Zend-Engine-1-Kompatibilität zu entfernen, ist sehr verständlich. Sie diente eigentlich nur der Abwärtskompatibilität beim Kopieren von Objekten und wurde kaum praktisch eingesetzt.
Interessantes
PHP 6: Alt und neu
Heiß diskutiert wurden und werden neue Funktionen, die schon länger auf der Wunschliste stehen. Beispielsweise war eine Idee, ein goto-Konstrukt in PHP zu integrieren, wie es etwa aus Basic bekannt ist. Allerdings sollte es nicht wie in Basic an beliebige Stellen springen können, sondern war eher für Fallunterscheidungen und Schleifen gedacht. Da es hier bereits die break-Anweisung gibt, wurde beschlossen, diese nur mit einem Label zu erweitern, auf das dann gesprungen werden kann. Das heißt, im folgenden Code wird in den ersten beiden Schleifendurchläufen einfach die Ausgabe vor Label übersprungen.
Andere schon länger gewünschte Funktionen wie ifsetor(), eine Funktion zum Setzen von Variablenwerten für Variablen, die noch keinen Wert besitzen, wurden dagegen abgelehnt beziehungsweise in diesem Fall dadurch erreicht, dass der konditionale Operator (Bedingung ? Wert : Alternativwert) auch mit leerem Wert verwendet werden kann. Gerade im Bereich der Objektorientierung wurden einige Wünsche abgelehnt, die aus anderen objektorientierten Sprachen zwar bekannt sind, für eine Webskriptsprache wie PHP aber nicht notwendig erscheinen. Einzig die Diskussion rund um Namespaces ist nach wie vor im Gange.
In den Kern
Dank der Aufräumarbeiten verschwinden einige Dinge aus dem PHP-Kern beziehungsweise aus der Distribution. Dafür werden neue integriert. In der Sache wenig überraschend ist die Integration eines Opcode-Caches, also eines Zwischenspeichers für PHP-Skripts. Zwar ist das für kommerzielle Cache-Lösungen keine gute Nachricht, aber andererseits gibt es schon länger einige sehr erfolgreiche Open-Source-Lösungen. Für die Integration wurde das entsprechende PECL-Paket APC (Alternative PHP Cache, pecl.php.net/package/APC) gewählt. Es soll allerdings nicht standardmäßig aktiviert sein, da der Administrator einige Konfigurationseinstellungen vornehmen muss.
In der PHP-Distribution landen sollen auch die PECL-Pakete xmlReader und xmlwriter, dann sicherlich mit vereinheitlichter Groß- und Kleinschreibung. Diese Pakete erlauben den Zugriff und das Schreiben von XML mit einem einfachen Parser, der an die von Microsoft in .NET eingeführten Parser erinnert. Dabei wird das XML-Dokument der Reihe nach durchgegangen und auf jeden Knoten kann zugegriffen werden. Im Gegensatz zum SAX-Ansatz sind dabei keine Ereignisse und Eventhandler im Spiel, sondern normale Schleifen übernehmen die Arbeit.
Aus dem Kern verschwinden sollen die POSIX-regulären Ausdrücke (zum Beispiel mit der Funktion ereg). Sie werden in PECL ausgelagert, die im PHP-Code vorhandenen Stellen werden auf die PCRE (Perl-kompatible reguläre Ausdrücke) umgeschrieben und mit Unicode gibt es noch eine neue Unicode-konforme Variante. Eine andere Erweiterung, die hinzukommt, ist fileinfo. Diese PECL-Erweiterung liefert Informationen zum Mime-Typ von Dateien. Dafür verschwindet mime_magic aus der Standarddistrib
ution. Standardmäßig aktiviert und vor allem um Sicherheitsfunktionen aufgebohrt werden soll die Web-Service-Erweiterung.
Bei den hier genannten Umschichtungen wird es sicherlich noch einige Änderungen geben. Gerade die Frage, welche Erweiterungen aussortiert oder ersetzt werden, wird erst nach und nach und für jede Erweiterung einzeln entschieden. Die meisten Entscheidungen werden sich hier aber glücklicherweise nur auf wenige Anwendungen niederschlagen. Und dadurch, dass nicht mehr mitgelieferte Erweiterungen in PECL wandern, sind sie zumindest noch auf dem Webserver integrierbar.
Ein Code für alle
PHP 6: Alt und neu
Die aufsehenerregendste Neuerung von PHP 6 ist sicherlich die brandneue Unicode-Unterstützung. Damit rüstet PHP ein Feature nach, das von den Anwendern seit Jahren gewünscht wird und das andere Webtechniken bereits länger in ihrem Repertoire haben.
Doch was ist überhaupt Unicode? Es handelt sich dabei um einen Zeichensatz, der allen unterstützten Zeichen eine bestimmte Nummer zuweist. Das an sich ist ja nichts Besonderes. PHP ist es im Grunde genommen sogar ziemlich egal, welcher Zeichensatz und welches Encoding verwendet werden.
In PHP-Versionen vor 6 waren alle Strings exakt ein Byte lang. Das funktioniert so lange gut, so lange eine Zeichenkodierung zum Einsatz kommt, die ebenfalls nur ein Byte pro Zeichen verwendet. In einer immer mehr zusammenwachsenden Welt – gerade durch das Internet – reichen aber die Möglichkeiten von einem Byte (insgesamt 8 Bit, also 256 verschiedene Zeichen) nicht mehr aus. Mit zwei Byte beispielsweise erhöht sich schon die Anzahl der Möglichkeiten auf 65536 verschiedene Zeichen. Bei vier Bytes pro Zeichen sind es sogar 4294967296 Möglichkeiten.
Unicode unterstützt momentan fast 100000 verschiedene Zeichen – damit sind alle Sprachen repräsentiert. Viel besser noch: Werden neue Zeichen entdeckt oder geschaffen – man denke nur an ein Beispiel aus der jüngeren Vergangenheit, das Euro-Zeichen -, so ist in Unicode immer noch Raum dafür. Platz ist für etwa das Hundertfache des momentanen Umfangs. Die drei möglichen Encodings sind UTF-8, UTF-16 und UTF-32, das entspricht einem, zwei beziehungsweise vier Bytes pro Zeichen.
Unicode-Unterstützung
PHP 6 bietet also Unicode-Unterstützung. Die gute Nachricht: Das Ganze ist abwärtskompatibel, denn wer bis dato stets nur mit Ein-Byte-Zeichen gearbeitet hat, kann das weiterhin tun. Die Unicode-Funktionalität ist also eine optionale Erweiterung. Dabei hat das PHP-Team beziehungsweise der dafür hauptverantwortliche Entwickler, Andrei Zmievski nicht die komplette Arbeit alleine geleistet. Von IBM gibt es die ICU-Bibliothek (International Components for Unicode), die sich um viele Aspekte des Arbeitens mit Unicode kümmert.
Allerdings ist diese Bibliothek einige Megabyte groß. Aus diesem Grund wird sie in PHP 6 nur auf Wunsch aktiviert. Die php.ini-Konfigurationseinstellung unicode.se
mantics gibt an, ob Unicode aktiv sein soll oder nicht. Gleichzeitig wollen die PHP-Kernentwickler auf die Macher hinter den verschiedenen Linux-Distributionen einwirken, dass diese zum Erscheinen von PHP 6 die ICU-Bibliothek ebenfalls mit ihren Paketen mitliefern, damit von vornherein das neue PHP-Feature eingesetzt werden kann.
Erste Messungen haben ergeben, dass PHP 6 mit deaktiviertem Unicode nicht wesentlich langsamer ist als PHP 5. Der Geschwindigkeitsunterschied zwischen PHP 5 ohne Unicode und PHP 6 mit Unicode ist allerdings erheblich; die String-Verarbeitung erfordert nämlich einiges an Rechenpower. Dafür steht Unicode dann überall zur Verfügung – wirklich überall. Folgender Code beispielsweise ist dann möglich:
Ob das nun guter Programmierstil oder gut wartbar ist, steht dabei auf einem anderen Blatt. Wenn Sie aller-
dings diesen Code ausführen und dann var_dump($Über
raschung) aufrufen, erhalten Sie als Ausgabe den Wert der Variablen (OTTO) sowie ihren Datentyp – unicode. Dazu ist es allerdings wichtig, dass Sie die Datei selbst auch in einem Unicode-Encoding (etwa UTF-8 abspeichern). Andernfalls erhalten Sie eine Fehlermeldung, da die Kodierung des Skripts kein Unicode einsetzt und PHP somit nicht mit den Sonderzeichen im Variablennamen umgehen kann.
Konsequenzen
PHP 6: Alt und neu
Obwohl viele Entwickler, die an PHP-Applikationen arbeiten, vom neuen Haupt-Feature Unicode gar nichts mitbekommen werden – der Abwärtskompatibilität sei Dank -, stehen die Kernentwickler vor einer Sisyphusarbeit. Fast überall dort, wo in PHP Strings verwendet werden, ist eine Anpassung notwendig.
Auf der Zend Conference 2006 in San Jose gab Andrei Zmievski bekannt, dass rund 40 Prozent der Funktionalität in den diversen PHP-Erweiterungen bereits fit für Unicode gemacht worden ist, inklusive der XML- und Web-Services-Erweiterungen. Diese Aussage von Zmievski sorgte für ein anerkennendes Raunen im Publikum.
Für Ende des Jahres ist eine spezielle Preview-Version des Unicode-PHP-6 vorgesehen, aber schon heute gibt es mehrmals pro Tag frische Snapshots von PHP 6 unter snaps.php.net.
Die weiteren Änderungen in PHP 6 sind aber in der Tat für viele Entwickler relevant; vor allem für solche Projekte, die entweder schlechten Code enthalten oder historisch gewachsen sind: PHP 6 schneidet endlich einige alte Zöpfe wie register_globals, magic_quotes und safe_mode ab, die schon beim Sprung von PHP 4 nach PHP 5 für einige Probleme gesorgt haben. Wer sich jedoch in den letzten paar Jahren, also spätestens mit der Einführung von PHP 5, an die Empfehlungen der PHP-Entwickler gehalten hat, muss hier keinen oder zumindest nur wenig Code ändern. Wer sich jedoch gegen den sich abzeichnenden Trend gestellt hat, muss spätestens beim Umstieg auf die Version PHP 6 die längst überfällige Anpassungen durchführen.
Bleibt zum Schluss nur noch eine Frage: Wann erscheint PHP 6? Die wohl beste Antwort darauf gab es ebenfalls auf der Zend Conference 2006: Hoffentlich vor dem lange verzögerten Perl 6.