PHP 5.4.0 in Debian Testing
in PHP | Tags: PHPDa hatte ich mir das Paket gerade selbst kompiliert, um die ganzen neuen Features gleich einmal zu testen. Und schon ist es passiert: Ganz offiziell zog gestern die Version 5.4.0 von PHP in Debian Testing ein.
Cool finde ich am neuen PHP vor allem Traits, die hybride Objekte ähnlich dem Polymorphismus in C++ erlauben. Seit Java war das ja verpönt und galt als “unbeherrschbar” ähnlich wie Atomkraftwerke. Stattdessen sollte man lieber mit diesen leeren Worthülsen von Interfaces werkeln. Doch die erlauben zwar eine gewisse Formalisierung von Analogien, aber keinen echten DRY-Code. Mit Traits ist man “im Objekt” und kann daher in $this schalten und walten wie man möchte – was witzige Sachen erlaubt.
Der nun in PHP selbst eingebaute Webserver ist allerdings nicht so das, was ich mir vorstellte. Eher zum Testen gedacht, durchläuft er pro Request jede PHP-Datei noch einmal und baut alle Objekte immer neu auf. Es ist also keine Deploy-and-Run-Lösung wie ein Zend Server. Immerhin kann man beim Testen schnell per F5 wissen, ob alles so läuft wie man möchte. Und für Bibliotheken kann man eine kleine launch.sh beilegen, die die Lösung auch ohne Webserver an Ort und Stelle demonstriert. Allerdings beantwortet der Server nur einen Request auf einmal, was ihn als echten Ersatz für den mittlerweile vielen als zu fett geltenden Apache nichtig macht.
Neu hinzugekommen ist übrigens die Restriktion, dass man eine date.timezone-Einstellung per ini benötigt, sonst gibts eine dicke Warnung beim Erzeugen eines Datetime-Objekts. Ansonsten ist glaube ich noch der Safe-Mode entfallen und die ganzen unnützen magic-quotes-Sachen…Vielleicht noch interessant sind die neuen Schnellzugriffe auf Arrays – erzeugen per [1,2,3] und auch bei der Rückgabe einer Funktion kann jetzt direkt darauf zugegriffen werden: getArray()[5] – das schreit geradezu nach try-catch.
Auf jeden Fall bewegt sich PHP (wie so oft) in die richtige Richtung. Aus der Spaghetti-Sprache für blinkende Vereinshomepages ist mittlerweile eine Feature-H*re geworden, die neben neuen Features rechtzeitig auch über Konsolidierung nachdenken sollte – auf Abwärtskompatibilität muss man eben manchmal verzichten.
SVN: subversion wird immer git-ter
in Linux, Open Source | Tags: Git, Subversion, SVNIch habe letztens bei einer Diskussion mit Kollegen gehört, dass Subversion ab Version 1.7 (10/2011) nicht mehr diese häßlichen verstreuten .svn-Verzeichnisse benötigt. Das ist doch mal was! Was war das nur für ein Krampf… Die Info ist auch Anlass, um zu schauen, was sich sonst noch geändert hat.
Natürlich ist das neue zentrale .svn-Metadata-Verzeichnis bereits für sich eine große Sache. Aber auch die interne Struktur der Metadaten hat sich verändert: Komprimierte Ablage von Daten (hat git auch), Hashes auf Datei-Inhalte (hat git auch), damit auch die Verwendung von Referenzen bei gleichem Inhalt (hat git auch) und in der nächsten Version soll es wohl auch Stashes (temporäre Änderungs-Speicher) unterstützen – das hat git bereits.
Dann gibt es noch ein Feature namens Merge-Infos, die sich verbessert haben sollen. Hatte ich nie benutzt, ich weiß also nicht, was diese Merge-Infos bringen. Vom Namen her wüsste ich aber ungefährt, dass ich mir bei Git einen diff der beiden Vorgänger-Versionen zum Merge-Commit anschauen könnte, um eine “Info” über einen “Merge” zu bekommen. Und, das klingt auch toll: In-Memory-Caching auf SVN-Server-Seite. Das klingt tatsächlich schwer bei git umsetzbar, schließlich kann man das git-Protokoll oder http benutzen, muss aber nicht, und über ssh doch gehts auch. In der letzten Situation würde der In-Memory-Cache nicht ziehen, höchtens aufwändig zu invalidieren sein.
Noch ein Feature heißt “Optimierte Netzwerkübertragung”, vorrangig durch Komprimierung. Hier habe das Gefühl, das müsste git bereits so umsetzen, denn die Daten werden ja im Repo bereits komprimiert abgelegt, ganze ungeänderte Subtrees werden nur als Referenz von Revision zu Revision übernommen und wer mal auf einen aufwändigen Übertragungsprozess geschaut hat, sieht auch, wie vor der Übertragung ermittelt wird, welche Daten tatsächlich über den Äther müssen.
Also alles in allem habe ich den Eindruck, Subversion wird immer gitter. Ketzerische Frage meinerseits folglich: Warum traut sich das Subversion-Team nicht, SVN einfach wegzuwerfen und ihre Fähigkeiten im Git-Team einzubringen? Das wäre doch mal der berühmte Sprung über den Schatten. Oder braucht man tatsächlich zwei (inkompatible) Versionskontrollsysteme, von denen das eine die Fähigkeiten des anderen Stück für Stück nachprogrammiert?