HaXe (Programmiersprache)

haXe
Entwickler:	Motion Twin
Aktuelle Version:	2.0
Betriebssystem:	Windows, Linux, Mac OS X
Kategorie:	Programmiersprache / Compiler
Lizenz:	GNU GPL
Deutschsprachig:	nein
haxe.org

haXe ist eine vollkommen objektorientierte, ECMAScript-ähnliche Programmiersprache. Die Möglichkeit, aus haXe-Code ausführbare Programme für Adobe Flash, JavaScript, PHP und Neko VM zu erzeugen,^[1] zusammen mit leistungsfähigem Remoting (Fähigkeit, Objekte und Methodenaufrufe an andere Systemen zu senden, siehe eigener Abschnitt), machen haXe ideal für die Programmierung von Webanwendungen, weshalb es auch als universelle weborientierte Sprache bezeichnet wird.

Geschichte

Die französische Firma Motion Twin wurde 2001 gegründet und beschäftigt sich seitdem mit der Entwicklung von Flash-basierten Webseiten und Spielen. Die Entwicklung von haXe ist eng mit der Firmengeschichte verwoben. Als Erfinder von haXe gilt Nicolas Cannasse, Mitbegründer von Motion Twin.

2003 bis 2005: Tools für die Arbeit mit ActionScript

Um sich die Arbeit mit ActionScript zu erleichtern, begann Motion Twin im Dezember 2003 mit der Entwicklung der ActionScriptMetaLanguage. Darin geschriebene Programme werden durch einen eigenen Vorcompiler in gewöhnliches Actionscript umgewandelt. In diesem Schritt wird Typ- und Parameterprüfung zu Compilezeit durchgeführt, wobei auch die weiter unten erläuterte Typinferenz zum Einsatz kommt. Der Resultierende ActionScript-Code wird dann mittels des Compilers von Flash in eine SWF-Datei umgewandelt, welche dann beim Nutzer mittels Flash Players angezeigt wird. Zum Vergleich: Ohne den Einsatz der ActionScriptMetaLanguage wird die Typprüfung erst zur Laufzeit möglich, was das Auffinden von Programmfehlern erschwert.

Im April 2004 wurde die ActionScriptMetaLanguage um neue Typen erweitert und nannte sich von da an MotionTypes. Wenig später erhielt der Compiler die Fähigkeit, direkt SWF-Bytecode zu erzeugen, ohne den Umweg über den Macromedia-Compiler zu gehen.

Sowohl ActionScriptMetaLanguage als auch MotionTypes werden nur innerhalb der Firma genutzt. Im Gegensatz dazu wurde MTASC, der MotionTwin Actionscript Compiler im Oktober 2004 als Betaversion der Öffentlichkeit vorgestellt. Dieser Compiler ist unabhängig von MotionTypes, denn er erstellt aus gewöhnlichem ActionScript (welches inzwischen die Sprachversion 2.0 erreicht hatte) SWF-Bytecode. Zusammen mit anderer freier Software ergab sich das Programmpaket FAMES (bestehend aus Flashout, ASDT, MTASC, Eclipse und SwfMill), womit es erstmals möglich war, Flashapplikationen auch ohne die proprietäre Software von Macromedia bzw. Adobe zu erstellen.

Am 14. Juli 2005, nur zwei Tage nach der öffentlichen Vorstellung des Flash Player 8, unterstützte MTASC bereits diese Flash-Version.^[2]

Ab 2005: Aufbau einer eigenen Sprache und Technologie

Zunächst wurde geplant, die (ebenfalls von Motion Twin entwickelte) Sprache Neko zukünftig in den Mittelpunkt zu stellen, und Neko mit anderen Technologien, wie z. B. ActionScript 2.0, Java und Ruby, zu kombinieren.^[2]

Als seitens Adobe ActionScript 3.0 angekündigt wurde, und die zahlreichen Nutzer von MTASC darauf warteten, dass die neuen Sprachfeatures von MTASC unterstützt würden, kündigte Motion Twin an, die Entwicklung einzustellen und stattdessen die neue Technologie haXe voranzutreiben.^[3]

Die Entwicklung begann am 22. Oktober 2005. Nach Alphaversionen im November 2005 und Betaversionen um Februar 2006 folgte am 17. Mai 2006 die Releaseversion 1.0. Die Aktuelle Version ist 2.0, welche am 24. März 2008 veröffentlicht wurde.^[4] Der haXe-Compiler und die mitgelieferten Bibliotheken sind freie, offene Software unter der GNU General Public License.^[5]

Benennung und Aussprache

Der Name haXe wurde gewählt, weil er „kurz, einfach und cool“ ist, und ein X enthält, was dem Autor zufolge nötig ist, damit eine neue Technologie erfolgreich werden kann.^[6]

Es gibt keine offizielle Aussprache des Namens haXe. International verbreitete Aussprachen sind „hex“ (welches einer französischen Aussprache nahe kommen soll), „häcks“ und „aytch äx“.^[7]

Sprache

haXe ist eine eigenständige Programmiersprache, die sich syntaktisch an ECMAScript bzw. ActionScript und Java anlehnt, jedoch auch eigene Syntaxelemente einführt.

Syntaxübersicht

Das folgende Codebeispiel bietet einen Überblick über den typischen Aufbau einer haXe-Quelltextdatei. Dabei zeigt es auch einige fortgeschrittene Möglichkeiten, die vom Programmierer nicht zwingend beherrscht werden müssen:

package my.pack;
 
import flash.Lib;
 
/** Dokumentation im Javadoc-Stil */
class MyClass<EinTyp> extends MyOtherClass, implements MyInterface {
 
    private var id : Int;
    private static var idCounter : Int;
 
    public var typisierteVariable : EinTyp;
 
    // Es folgt eine Eigenschaft samt get- und set-Methode. 
    // Der Typ der Eigenschaft wird als Typenparameter angegeben.
    public var x(getX,setX) : EinTyp;
    private var my_x : EinTyp;
 
    private function getX() {
        return my_x;
    }
 
    private function setX( v : EinTyp) {
        my_x = v;
        trace("Wert von x wurde geändert!");
        return my_x;
    }
 
 
 
    /** Dies ist ein Konstruktor */
    public function new()
    {
        id = idCounter++;
    }
 
    function foo() : Void {
        for(x in 3...7)
            trace("Eine Zahl " + x);
    }
 
    /** Einsprungpunkt für die Anwendung */
    static function main()
    {
        var instanz = new MyClass<Bool>();
        instanz.x = true;        // ruft den setter auf, welcher eine Warnung per trace ausgeben wird
    }
}

An dieser Stelle sei nochmal betont, dass dieser Code ohne Änderungen in allen drei Compiler-Zielen lauffähig ist.

Featureübersicht

Die meisten der folgenden haXe-Features sind auch aus weit verbreiteten objektorientierten Sprachen wie C++ oder Java bekannt und werden daher nicht näher erläutert:^[8]

• Strukturierung großer Projekte mittels packages
• Dokumentation mittels speziellen, Javadoc-ähnlichen Kommentaren
• Klassen mit Typparametern, wobei neuere Versionen Template-ähnliche Vorzüge bieten
• Einfachvererbung und das Implementieren von (auch mehreren) Interfaces
• Zugriffsmodifikatoren wie z. B. private und static
• Eigenschaften, deren Zuweisung über Zugriffsfunktionen (Getter und Setter) abgewickelt wird
• Konstruktoren
• Main-Methode muss auch innerhalb einer Klasse untergebracht sein
• For-Each-Schleife (andere Formen der For-Schleife gibt es in haXe nicht)
• Iteratoren (im Codebeispiel nicht gezeigt)
• Reflection (im Codebeispiel nicht gezeigt)

Folgende Features, die viele gängige Sprachen bieten, fehlen jedoch in haXe:

• Methodenüberladung
• Mehrfachvererbung
• Abstrakte Klassen

Typinferenz

Programmiersprachen sind für gewöhnlich statisch oder dynamisch typisiert. Bei statischer Typisierung ist jeder Variable, jedem Attribut und jedem Parameter eindeutig ein Typ zuzuordnen, der zur Laufzeit konstant bleibt.

// Java-Beispiel (Java ist statisch typisiert):
int x;
x = 3;       // geht
x = "hallo"; // geht nicht

In einer dynamisch typisierten Sprache haben Variablen, Attribute und Parameter keinen klar definierten Typ:

// Javascript-Beispiel (Javascript ist dynamisch typisiert):
var x;
x = 3;       // geht
x = "hallo"; // geht

haXe verbindet beide Ansätze. Zum einen ist es dem Programmierer freigestellt, ob der Typ einer Variablen angegeben wird, oder nicht. Zum anderen schlussfolgert (Inferenz bedeutet Schlussfolgerung) der Compiler selbständig den Typ jeder Variable, die nicht vom Programmierer festgelegt wurde, und behandelt sie, als wäre sie statisch typisiert. Als dritte Alternative kann der Programmierer sie explizit als Dynamic deklarieren und somit die Typinferenz aushebeln:

// haXe-Beispiel (in diesem Fall statisch):
var x : Int;
x = 3;       // geht
x = "hallo"; // geht nicht
 
// haXe-Beispiel (in diesem Fall statisch durch Typinferenz):
var x;
x = 3;       // geht, Compiler schließt darauf, dass x vom Typ 'Int' ist
x = "hallo"; // geht nicht
 
// haXe-Beispiel (in diesem Fall dynamisch):
var x : Dynamic;
x = 3;       // geht
x = "hallo"; // geht

Die Sprachen, für die haXe einen Ersatz darstellen kann (Javascript, ActionScript, PHP, etc.) sind in der Regel dynamisch typisiert. Der Vorteil der Typinferenz sei nochmals an folgendem Beispiel gezeigt:

function bar() : Array<Int> {
    var retval = [1,2,3,4];
    if(Math.random() < 0.001)   // Math.random() liefert zufälligen Wert zwischen 0 und 1
        retval.push(5.001);     // ACHTUNG: Diese Zeile erzeugt einen Compiler-Fehler
    return retval;
}

Das Array retval ist vom Programmierer nicht typisiert. Jedoch kann der Compiler aus dem Methodenkopf erkennen, dass das Array vom Typ Int sein muss, um später als Rückgabewert zu dienen. Das Einfügen des Wertes 5.001 widerspricht dem, somit wird der Compiler einen Fehler melden. Ohne Typinferenz würde dieser Fehler erst zu Laufzeit auffallen, und auch erst bei Ausführung der markierten Zeile. Auf Grund der if-Bedingung würde dies erst nach ca. 1000 Testläufen auftreten, d. h. eventuell erst, wenn die Software zum Kunden ausgeliefert wurde.

Konditionales Compilieren

Ein Großteil des haXe-Codes ist auf allen Zielplattformen lauffähig (siehe Abschnitt Zielplattformen). Dennoch kommt man oft nicht um plattformspezifische Anpassungen herum. Diese können wie folgt eingebunden werden:

#if flash
    // haXecode für Flash-Plattform (beliebige Version)
    // z.B. wird folgendes ein Quadrat mittels eines Flash-MovieClip-Objektes anzeigen:
    var mc : flash.MovieClip = flash.Lib.current;
    mc.beginFill(0xFF0000);
    mc.moveTo(50,50);
    mc.lineTo(100,50);
    mc.lineTo(100,100);
    mc.lineTo(50,100);
    mc.endFill();
#elseif js
    // haXecode für Javascript-Plattform
    // z.B. Zugriff auf das Browser-DOM um etwas anzuzeigen
#elseif neko
    // haXecode für die  neko-Plattform
#error 
    // wird automatisch den Fehler "Not implemented on this platform" ausgeben
#end

Aufzählungstypen

Aufzählungstypen sind eine Schlüsselfunktion der Sprache. Sie können selbst Parameter haben und rekursiv sein, was ihnen erlaubt, wie Klassen behandelt zu werden.^[9] Enums in haXe sind nicht einfach nur indizierte „magic-numbers“ wie in den meisten Sprachen, sondern sind abstrakter: Sie haben keinen eigenen Wert, aber können instantiiert werden, wie das folgende Beispiel zeigt:

    enum Farbe {
        rot;
        gruen;
        blau;
        rgb: ( r : Int, g : Int, b : Int );
    }
 
    class Farben {
        static function nachInt( c : Farbe ) : Int {
            return switch( c ) {
                case rot: 0xFF000;
                case gruen: 0x00FF00;
                case blau: 0x0000FF;
                case rgb(r,g,b): (r << 16) | (g << 8) | b;
            }
        }
        static function gueltigeAufrufe() {
             var rotint = nachInt(rot);
             var rgbint = nachInt(rgb(100,100,100));            
        }
    }

(Aus der haXe-Referenz, modifiziert)

Weitere Details

Funktionsparameter können in haXe sehr genau definiert werden:

function mehrereParameter(dreidimensionalsArray : Array<Array<Array<Int>>>, stringval : String, boolval : Bool) {}
function optionalerParameter( ?i : Int ) : Int {return 0;} // optional int value returning an int
function funktionAlsParameter( f : Void -> Void ) {f();} // call a function with no parameters 
function eineAndereFunktionAlsParameter( f : Int -> Int ) {var result = f(1);} // call a function that returns an int, with an int parameter
function kannAllesMoeglicheSein(d : Dynamic) : Dynamic {return d;} // function which takes any kind of type and returns it

Zielplattformen

In haXe geschriebener Code wird compiliert (im Gegensatz zu anderen Sprachen, welche interpretiert werden). Dabei kann man zwischen folgenden Zielen wählen:

• Flash, genauer:
  • SWF-Bytecode für AVM 1 (entspricht Flash 6,7,8)
  • SWF-Bytecode für AVM 2 (entspricht Flash 9)
  • Actionscript 3.0 Sourcecode
• Javascript
• Neko VM
• PHP (Seit Version 2.0)
• eventuell Java Bytecode (in Planung/Diskussion)^[10]

Das ansonsten eher unbekannte Neko verdient hierbei besondere Beachtung: Es kann einerseits serverseitig eingesetzt werden (als Standalone-Server oder als Apache-Modul modneko). Andererseits kann es auch direkt beim Client eingesetzt werden. Dazu muss dieser die Neko-VM auf seinem Rechner installieren. Mittels Screenweaver HX ist es möglich, Desktopanwendungen mittels haXe umzusetzen, bei denen die Logik in Neko umgesetzt ist, das Userinterface jedoch mittels Flash.

Seit der Version 2.0 wird auch PHP als Serverseitige Sprache unterstützt, welches auf Webservern meist vorinstalliert ist, im gegensatz zur eher unbekannten Neko VM.

In haXe geschriebene Klassen kann man nach der Compilierung als SWF in Actionscript-Code verwenden, umgekehrt können compilierte Actionscript-Klassen von haXe Code verwendet werden, man kann sogar davon ableiten.

Bibliotheken und APIs

Der Sprachkern von haXe und eine Reihe von mitgelieferten Bibliotheken sind für alle Zielplattformen verfügbar. Dazu gehören zwei verschiedene XML-APIs (beide sind überall verfügbar), reguläre Ausdrücke, Exceptions, Remoting, Reflection, Math (trigonometrische Funktionen, Pseudozufallszahlen, etc.) und der Umgang mit Daten und Zeiten. Solange eine Klasse nur von diesen APIs Gebrauch macht, kann sie ohne jegliche Anpassungen für alle Ziele compiliert werden. Es ist für den Programmierer irrelevant, ob es sich dabei um Wrapper handelt (welche eine native Bibliothek kapseln), oder diese komplett in haXe implementiert sind. Sprachmerkmale von haXe, die in der Zielsprache nicht vorhanden sind (z. B. Interfaces, Generik, etc.) bereiten hierbei keine Probleme, denn sie werden vom Compiler in equivalenten Code umgesetzt.

Darüber hinaus bietet haXe vollen Zugriff auf die plattformspezifischen APIs. Bei Flash betrifft das z. B. MovieClips und Grafikfilter, bei Javascript die Interaktion mit dem Browserfenster, und bei Neko zugriff auf Systemressourcen wie etwa lokale Dateien.

Userinterfaces

haXe ermöglicht zwar, Großteile des Userinterfaces damit umzusetzen, jedoch stößt die Portabilität hier eindeutig an ihre Grenzen. Es ist somit nicht möglich, ein einziges Userinterface zu schreiben, welches in Flash, HTML/Javascript und als Desktopanwendung zugleich lauffähig ist. Dennoch ist es möglich, zwei bzw. drei getrennte Userinterfaces zu schreiben, die auf denselben Anwendungskern zugreifen. Aus Sicht des Kerns können diese Userinterfaces das gleiche Klasseninterface besitzen. Mit entsprechendem Aufwand wäre es also möglich, ein solches portables Framework für Userinterfaces zu schaffen, nur existiert es bisher nicht.

Rich Internet Applications – Vergleich zwischen haXe und anderen Lösungen

Heutige Rich Internet Applications unterscheiden sich von klassischen Webseiten dadurch, dass sich zunehmend Anwendungslogik vom Server auf den Client verlagert. Dies ermöglicht schnellere Reaktionen auf Benutzereingaben, weniger Traffic und ein Desktop-ähnliches Look and Feel. Um solche RIAs zu entwerfen waren bis vor kurzem eine Vielzahl von Programmiersprachen nötig. haXe und auch andere aktuelle Ansätze (siehe Ende des Abschnitts) ermöglichen die Arbeit mit einer einzigen Sprache.

Umsetzung mit mehreren Sprachen

Zum Erstellen von RIAs konkurrieren seit längerem zwei Technologien: AJAX und Flash. Zwar sind Java Applets die älteste und ausgereifteste Technologie in diesem Bereich, konnten jedoch beim durchschnittlichen Nutzer nie die Bedeutung von Javascript und Flash erreichen. Neue Technologien wie JavaFX, das Flash-basierte Flex und Microsoft Silverlight drängen ebenfalls in diesen Bereich, indem sie neue Sprachen (JavaFX Script, MXML und XAML) einführen, die meist mit den bereits vorhandenen kombiniert werden.

Allen Konzepten gemeinsam ist, dass die Internetanwendung verteilt abläuft: Das Userinterface und zeitkritische Teile der Logik laufen beim Client (innerhalb des Webbrowsers), die Datenhaltung und alle sicherheitsrelevante Logik befindet sich auf dem Server. Die Kommunikation findet asynchron (d. h. vom Anwender unbemerkt im Hintergrund) mittels HTTP statt. Um diese Webanwendungen auch offline und ohne Browser verfügbar zu machen, muss der Nutzer auf seinem Rechner auch die Teile ablaufen lassen, die ursprünglich auf den Server ausgelagert wurden. Dies wird teilweise durch AIR (Adobe Integrated Runtime) und Gears ermöglicht.

Quasi alle oben genannten Techniken erfordern vom Entwickler, verschiedene Sprachen zu beherrschen, im Extremfall sind dies HTML, CSS, XML, JavaScript, ActionScript und eine Serverseitige Sprache wie z. B. PHP, Ruby, Perl oder Java. Zudem müssen die Einzelteile auch sprachübergreifend zusammenarbeiten, wofür meist ein XML- oder ein textbasiertes Interface zwischen diesen geschaffen werden muss. Die Arbeit mit diesen Sprachen wird dadurch erschwert, dass sie nicht nur eine andere Syntax, sondern oft ein komplett anderes Typsystem besitzen. So ist die Objektorientierung in Javascript grundverschieden von z. B. der in Java.

Umsetzung mit haXe

Bei der Entwicklung mit haXe können Server-, Client- und gegebenenfalls Desktop-Komponenten in derselben Sprache verfasst werden. Zudem ermöglicht es das haXe-Remoting, Objekte und Methodenaufrufe über Sprach- und Rechnergrenzen hinaus zu versenden. Somit muss der Entwickler

• nur noch eine Programmiersprache beherrschen (Auszeichnungssprachen wie HTML und CSS können weiterhin nötig sein)
• sich nicht frühzeitig entscheiden, ob ein Programmteil Client- oder Serverseitig ablaufen soll
• sich nicht frühzeitig entscheiden, ob er dem Benutzer eine Flash- oder AJAX-Oberfläche bieten möchte
• keine textuellen Interfaces zwischen den Anwendungsebenen entwerfen und implementieren

haXe bietet sich also vor allem bei mehrschichtigen Internetanwendungen an. Aufgrund von Sprachfeatures, die anderen Sprachen oft fehlen, kann haXe auch schon bei einfachen, einschichtigen Anwendungen die Entwicklung erleichtern.

Andere Ansätze mit einer einzigen Sprache

Sowohl Rich Ajax Platform als auch Google Web Toolkit ermöglichen dem Entwickler, RIAs zu entwickeln und dabei sowohl die Client- als auch die Serverseite in Java zu programmieren. Beide generieren daraus ein Servlet sowie clientseitgen Code in Javascript. Anders als haXe bieten beide eigene Widgets an, aus denen automatisch HTML-Seiten erzeugt werden. Im Gegensatz dazu erfordert haXe vom Entwickler, selbst HTML zu generieren, es sei denn, er verzichtet komplett auf den Einsatz von HTML. Flash wird von diesen beiden Lösungen nicht unterstützt, allerdings kann Rich Ajax Platform eigenständige Desktopanwendungen auf SWT-Basis erzeugen.

OpenLaszlo verwendet zwar nicht nur eine einzige Sprache, denn in den deklarativen XML-Dialekt LZX wird ECMAScript eingebettet. Ähnlich wie haXe kann OpenLaszlo daraus jedoch auch eine Flash- als auch eine DHTML-Oberfläche erzeugen. Insofern ist es haXe überlegen, da haXe seinerseits kein Userinterface generieren kann (siehe Abschnitt Userinterfaces).

Remoting

Der Abschnit Remoting fehlen folgende wichtige Informationen: Der Artikel stellt das Remoting der Versionen 1.x dar. In haXe 2.0 gibt es hier größere, nennenswerte Änderungen. (siehe [1]) Du kannst Wikipedia helfen, indem du sie recherchierst und einfügst.

haXe ermöglicht es, zwischen den unterstützten Plattformen quasi beliebig Objekte und Methodenaufrufe zu versenden. Dabei stehen in jedem Fall synchrone und asynchrone Verbindungen zur Verfügung. Das Verfahren ähnelt Remote Procedure Call.

So können Flash-Objekte und Javascripts innerhalb einer Seite untereinander kommunizieren, und beide können direkt auf einen Neko-Server zugreifen. Auf gleiche Weise können Server bzw. Neko-Desktopanwendungen auch untereinander kommunizieren. Darüber hinaus können mit haXe geschriebene Flashprogramme auf einen Flash Media Server (auch AMFPHP) zugreifen.^[11]

Folgender Quellcode könnte in Flash, Javascript oder einem zweiten Neko-Server benutzt werden, um auf einem Neko-Server die Methode meineMethode aufzurufen. Der Rückgabewert bzw. eine dort geworfene Exception wird an eine der beiden lokalen Callback-Methoden weitergeleitet:

// Verbindung zu Neko-Server aufbauen
var verbindung = haxe.remoting.AsyncConnection.urlConnect("http://einedomain.com/neko");
 
// anonyme Callback-Methode für den Fehlerfall anmelden
verbindung.onError = function(err) { trace("Fehler : "+Std.string(err)); };
 
// Callback-Methode für den Erfolgsfall
var beiErfolg = function(r) { trace("Rückgabewert : "+Std.string(r)); };
 
// Methode auf dem Server aufrufen. Entspricht dort dem Aufruf 
// mein.package.MeineAndereKlasse.meineMethode(0,1);
verbindung.mein.package.MeineAndereKlasse.meineMethode.call([0,1],beiErfolg);

Über die bei AJAX üblichen HTTP-Anfragen an den Server werden damit andere Einsatzmöglichkeiten denkbar. Ein mögliches Anwendungsbeispiel: Eine RIA mit HTML-Oberfläche und Anwendungslogik in Javascript enthält eine aufwändige Berechnung. Falls auf dem Nutzerrechner Flash verfügbar ist, wird sie an ein 1x1-Pixel großes Flashobjekt delegiert (unter der Annahme, dass Flash-Bytecode deutlich schneller ausgeführt wird als Javascript). Ist kein Flash verfügbar, so wird die Berechnung auf dem Server ausgeführt. Falls weder der Server noch Flash verfügbar sind, läuft die Berechnung lokal per Javascript. Die Berechnung selbst muss dabei nur ein einziges Mal in haXe implementiert werden.

Compiler-Implementierung und Performanz

Der haXe-Compiler ist in OCaml implementiert. Da haXe-generierter Code in virtuellen Maschinen läuft, ist keine Kenntnis von OCaml nötig um mit haXe Anwendungen zu entwickeln. Dies bedeutet auch, dass die Performanz je nach Zielplattform variiert, da jede Plattform angepasst werden muss um die vorhandenen Ressourcen bestmöglich zu nutzen.

Ein Benchmark^[12] zeigt, dass haXe Flash 9(AVM2) Bytecode mit besserer Performanz compiliert als der äquivalente AS3-Code auf Adobes Compiler. Seit diesem Benchmark wurde der Compiler noch weiter verbessert, u.A. durch die Hinzufügung von inline-Funktionen.

Um das Compilieren mehrerer Klassen für verschiedene Kompilierziele zu vereinfachen, werden hxml-Dateien verwendet. Dies sind einfache Textdateien mit Anweisungen für den Compiler. Per Doppelklick auf diese kann somit das gesamte Projekt compiliert werden.

Da der Compiler eine Kommandozeilenanwendung ist, lässt er sich auch in vorhandene Entwicklungsumgebungen einbinden. Flashdevelop bringt von Haus aus Unterstützung für Haxe mit sich.

Quellen

1. ↑ Einführung in haXe (deutsch).
2. ↑ ^{a b} MTASC-Folien auf der OSCON-Konferenz (pdf, englisch).
3. ↑ MTASC und Actionscript 3 (englisch).
4. ↑ Neuerungen in Haxe 2.0 (englisch).
5. ↑ haXe-Download-Seite (deutsch).
6. ↑ haXe Mailinglist-Beitrag zur Aussprache (englisch).
7. ↑ haXe Mailinglist-Beitrag zur Aussprache (englisch).
8. ↑ haXe Sprachreferenz (deutsch).
9. ↑ haXe Sprachreferenz über Enums (deutsch).
10. ↑ Mailinglist-Beitrag über Java (englisch).
11. ↑ haXe-Tutorial zu Remoting (englisch).
12. ↑ Portierung der Actionscript Physics Library nach haXe (englisch).

Weblinks

Offiziell

• haXe-Website (englisch, vollständig / deutsch, unvollständig)
• Webseite der entwickelnden Firma Motion Twin (französisch / englisch)
• Webseite des haXe-Vorgängers MTASC (englisch)

Inoffiziell

• Kurzvortrag über haXe (pdf, 900 kB, deutsch)