Ruby, Sapphire, Jade – ja, ich weiß, sehr einfallsreich, aber egal.

Nach vielen Überlegungen über den Kurs, den ich mit Sapphire eingeschlagen hatte, bin ich zum Entschluss gekommen, die Entwicklung einzustellen. Zu meinem gefällt mir das Design des Kern-Systems nicht mehr, zum anderen fehlt mir momentan einfach die Zeit für so etwas großes bzw. den Umbau.

Demnächst wird mein Blog auf Wordpress umgestellt. Entsprechede Import-Scripts für Einträge, Kommentare etc. habe ich schon geschrieben, es muss nur noch ein passendes Design her. Zwar finde ich den prozeduralen Programmierstil bzw. den Quelltext von Wordpress scheußlich und viele Plug-Ins entstammen der Code-Vorhölle, aber es hat einfach alles, was ich brauche und das ohne es aufwendig selbst entwickeln zu müssen.

Aber zurück zum Thema: Jade soll ein kleines, aber feines Framework für die schnelle Entwicklung von dynamischen Websites werden. Aus meiner Sicht machen viele Frameworks den Fehler und sind einfach zu groß bzw. zu überladen. Daher sind sie träge, intern zu kompliziert und auch teilweise schwer zu erlernen. Mit Jade versuche ich diese Fehler zu vermeiden. Es soll sich auf das Wesentliche konzentrieren, einfach zu verstehen und schnell sein. Trotzdem soll der Komfort nicht zu kurz kommen.

Hierfür bekommt Jade einen gänzlich anderen Aufbau als Sapphire, der zwar für sich gesehen gut funktioniert, aber zu kompliziert ist, um ihn noch sauber durchblicken zu können. Die Architektur richtet sich nach meinen Erfahrungen mit dem CMS Contenido, dem Shop-System Oxid eShop Community Edition 4 und den Fehlentwicklungen aus Sapphire.

Da ich hier niemanden langweilen will, spare ich mir technische Details für eine Projektseite, die Lauf des restlichen Jahres kommen wird. Dort gibt es genauere Auskünfte über die Architektur und die verwendete Technik.

Eins noch: wie ich weiter oben schon gesagt habe, wurde Sapphire auch aus Zeitmangel eingestellt. Jade wird zwar deutlich kleiner, aber Zeit fehlt mir immer noch – daher erwartet bitte keine Wunder.

Filme: Resident Evil Degeneration, Star Wars – The Clone Wars (uff)

Serien: Battlestar Galactica Season 4

Bücher: Stefan Aust – Der Baader-Meinhof-Komplex (ja, immer noch), Drew Karpyshyn – Darth Bane: Rule of Two

Zeitschriften: PHP-Magazin, MaxPlanckForschung

iTunes/iPod: Queen – Breakthru

Spiele: GTA IV (PC), iShoot (iPod)

Javascript-Bibliothek des Jahres 2008: jQuery

Ein kurzes Wort zur MaxPlanckForschung: sie wird vierteljährlich herausgegeben und kann kostenlos als PDF oder im Abonnement bezogen werden. Ich kann sie jedem, der sich für wissenschaftliche Magazine interessiert nur ans Herz legen. Die Texte erfordern aber teilweise viel Hintergrundwissen des Lesers, daher lest bitte erst ein Artikel online und abonniert nicht einfach blind, nur weil es kostenlos ist.

Wie schon angekündigt, habe ich mit dem Umstieg auf Netbeans begonnen, Sapphire komplett neu zu schreiben. Der eigentliche Kern ist nahezu fertig und die ersten Module in Arbeit – ging alles wesentlich schneller als erwartet. Daher werde ich Ruby nicht mehr weiter entwickeln und die bestehenden Module umschreiben.

Dinge, wie die Mandanten-Fähigkeit noch in Ruby zu integrieren, obwohl sie im Sapphire-Kern schon implementiert sind, ist sinnlos. Außerdem ermöglicht es die neue Struktur wesentlich schneller und besser, Änderungen am Hauptsystem vorzunehmen. Das Portieren der Ruby-Module sollte relativ schnell und unproblematisch laufen.

Die wichtigsten Unterschied zwischen Ruby und Sapphire:

1. Sapphire ist durchgängig objektorientiert, soweit es PHP 5 ermöglicht.
2. Es werden ausschließlich Prepared SQL Statements über MySQLi oder PDO unterstützt.
3. Die Fehler-Verwaltung läuft komplett über Exceptions (SPL und eigene).
4. Bessere und nun vollständige Implementierung des MVC-Patterns.
5. Alle Singleton-Patterns wurden entfernt.
6. Mandantenfähig von Anfang an.
7. Abstraktionsebene aller Superglobals.
8. Alle assoziativen Arrays wurden durch Instanzen der Klasse Data ersetzt.
9. Kleinere Änderungen an der Datenbank, u.a. für die Mandantenfähigkeit. (Ein Import-Script wie von Version 1 auf 2, ist nicht nötig.)

Insgesamt bin ich mit bisherigen Stand sehr zufrieden. Vieles ist im Vergleich zu Ruby einfacher geworden, ganz besonders der Modul-Manager – bei gleichem Funktionsumfang braucht er nur knapp die Hälfte des Quelltexts. Es ist nun wesentlich einfacher, zu überprüfen, ob ein Modul schon geladen ist und an dessen Funktionen heran zu kommen. Zusammen mit einem zukünftig implementierten Observer-Pattern und der Factory des Kerns, ist das die neue Modul-Schnittstelle.

Bekanntlich sind Arrays in PHP keine Objekte, wie es z.B. in C# oder Java der Fall ist. Dennoch ist es mit den Interfaces und vorgefertigten Klassen der Standard PHP Library (SPL) möglich, eine Klasse zu entwerfen, die sich wie ein Array verhält. Das mag überflüssig oder überdimensioniert erscheinen, aber ich halte es für ein gutes Beispiel, welche Dinge die SPL möglich macht:

<?php

class MyArray implements ArrayAccess, Countable, Iterator {
	
	private $data = array();
	public $length = 0;
	private $position = 0;
	private $keys = array();

	public function __construct() {
		$args = func_get_args();
		
		if(count($args) > 0) {
			foreach ($args as $key => $value) {
				$this->data[$key] = $value;
				$this->length++;
			}
			
			$this->keys = array_keys($this->data);
		}
	}

	public function __destruct() {
		unset($this->data);
	}

	public function __set($offset, $value) {
		return null;
	}

	public function __call($method, $args) {
		return null;
	}

	public function offsetExists($offset) {
		return isset($this->data[$offset]);
	}

	public function offsetGet($offset) {
		return $this->data[$offset];
	}

	public function offsetSet($offset, $value) {
		$this->data[$offset] = $value;
		$this->length++;
		$this->keys = array_keys($this->data);
	}

	public function offsetUnset($offset) {
		unset($this->data[$offset]);
		$this->length--;
		$this->keys = array_keys($this->data);
	}

	public function count() {
		return $this->length;
	}

	public function rewind() {
		$this->position = 0;
	}

	public function next() {
		$this->position++;
	}

	public function key() {
		return $this->keys[$this->position];
	}

	public function current() {
		return $this->data[$this->key()];
	}

	public function valid() {
		if($this->position < $this->length) {
			return true;
		}
		
		return false;
	}
}

?>

Interface ArrayAccess:

• offsetExists()
• offsetGet()
• offsetSet()
• offsetUnset()

Diese Methoden sorgen dafür, dass man das Objekt wie ein ganz normales PHP-Array benutzen kann, d.h. eine Einträge hinzufügen, ausgeben oder löschen.

Interface Countable:

• count()

Wie der Name schon sagt, gibt die Methode count() einfach nur die Anzahl der aktuellen Array-Items aus.

Interface Iterator:

• rewind()
• next()
• key()
• current()
• valid()

Wer vor PHP 4 schon anbord war, wird diese PHP-Funktionen sicher noch kennen, um assoziative Arrays über eine while()-Schleife zu iterieren. Und nichts anderes machen auch die entsprechenden Methoden. Nur sorgen sie in diesem Fall dafür, dass man das Array-Objekt mit foreach() durchlaufen kann.

Zusätzlich sind die magischen Methoden __set() und __call() leer implementiert, so dass man die Eigenschaft $length nicht überschreiben kann und nicht beabsichtigte Methodenaufrufe verhindert werden. Der Konstruktor ermöglicht außerdem wie bei array() beim Initialisieren Werte in das Array zu schreiben.

Vor knapp zwei Jahren habe ich mir diese Frage im Eintrag »Sorgenkind PHP« schon einmal gestellt. Seit dem hat sich leider kaum etwas getan: PHP 5.2 war 2006 die aktuellste Version und ist es immer noch, obwohl man damals davon ausging, dass PHP 6 im Laufe des Jahres 2007 erscheinen würde.

Die Entwicklung geht nur schleppend voran. Eigentlich sollte letzte Woche die finale Version 5.3 erscheinen, aber stattdessen kam nur die Alpha 3. Nun wird erste Quartal 2009 als Termin genannt. Momentan glaube ich eher, dass dann erst die Beta-Phase beginnt. An PHP 6 ist momentan gar nicht zu denken.

Sicher bringt 5.3 auch schon viele Neuerungen, u.a. Namespaces und Geschwindigkeitssteigerungen von bis zu 30%, aber langsam bin ich das Warten leid. Probleme wie die nicht einheitliche Namensgebung von integrierten Funktionen/Methoden und Klassen, nicht durchgängige Objektorientierung im Core und in vorhandenen Extensions und vor allem viele sicherheitsrelevante Dinge wie die Typisierung von skalaren Variablen bzw. Parametern oder bessere Möglichkeiten, Benutzereingaben zu kontrollieren, fehlen PHP einfach.

Zwar gibt es für viele dieser Probleme Lösungen durch Frameworks, Extensions oder Tricks. Wirklich zufriedenstellend ist das aber nicht. Andere Sprachen haben dieses Features von Haus aus implementiert und entwickeln sich ständig weiter.

PHP verliert mehr und mehr an Anschluss, wird aber trotzdem erfolgreich bleiben. Objektorientierte Programmierung ist kein Muss, Fehler werden großzügig verziehen und selbst der mieseste Schrottcode, liefert noch brauchbare Ergebnisse. Besonders letzteres ist ein Problem, aber zugleich auch der Grund für den anhaltenden Erfolg. Man muss nicht verstehen, was man programmiert, es funktioniert ja meist auch so.

Ich bin dafür, einen zweiten Entwicklungszweig für PHP einzuführen. Der erste wird so weitergeführt wie bisher, also Script-Kiddie-freundlich ausgerichtet und der andere wird von Grund auf neu entwickelt – mit allen Features, die eine moderne objektorientierte Sprache im Hinblick auf dynamische Websites braucht. Damit wären die Probleme gelöst und PHP bleibt trotzdem »einsteigerfreundlich«.