| Startseite | Einleitung | Funktionsweise | Verwendung | Kompiliergrade | Arbeiten mit advanced_optimizations | Fazit |
|---|
Die drei Kompiliergrade sind aufeinander Aufbauend. Das bedeutet, dass zum Beispiel advanced_optimizations alles macht, was auch bei den simple_optimizations gemacht wird und dann seine zusätzliche Funktionalität anwendet.
Wichtig ist es außerdem die Referenzierung von Programmelementen anhand von Strings zu meiden. Also sollte man niemals objekt["attributname"] verwenden. Strings werden vom Closure Compiler generell ignoriert und entsprechende Umbenennungen würden innerhalb der Strings nicht vorgenommen werden.
In dem Kompiliergrad whitespace_only werden alle Kommentare und Leerzeichen, sowie nicht notwendige syntaktische Elemente (zum Beispiel Semikolons nach jeder Anweisung) entfernt.
Das Ergebnis sieht dann in etwa so aus, als hätte man einen Screener auf dem Code angewand.
Durch das entfernen von Formatierung und Kommentaren können natürlich andere Programme, die eben diese Vorraussetzen, nicht mehr auf den Quellcode angewandt werden. Wenn man also eine Tool zum automatischen Dokumentieren anhand von JSDoc-Kommentaren verwenden möchte, so sollte man dies vor der Kompilierung durchführen. Auch die Funktionalitäten von conditional comments gehen verloren (auch wenn man diese generell nicht Verwenden sollte).
Bei der simple_optimization werden Umbenennungen und syntaktische Änderungen innerhalb von Funktionen und Ausdrücken vorgenommen.
Die Umbenennungen beschränken sich jedoch auf lokale Bezeichner für Variablen (also auch lokale Funktionen) sowie auf die Parameter von Funktionen im globalen Namensraum (da diese auch als lokale Variablen der Funktion angesehen werden können).
simple_optimization-Modus komprimieren möchte muss man beachten, dass man die with-Anweisung nicht Verwenden darf.
Der Kompiler kann hier nicht zwischen lokalen Variablen und Objektattributen mit dem selben Namen unterscheiden. Eine semantische Beständigkeit des resultierenden Programms kann also nicht mehr gewährleistet werden.
Die stärkste Komprimierung des Codes erhält man mit dem Closure Compiler im advanced_optimizations-Modus.
Dieser wendet seine Umbenennungen und syntaktischen Transformationen auf den gesamten Code an. Es werden nun auch die Attribute von Objekten umbenannt und unerreichbarer/ungenutzter Code wird entfernt.
Stellenweise werden sogar Objekte zu normalen Variablen "degradiert", wenn man dadurch die Länge des Codes verringert. Dazu wird dann für jedes object.attribut vorab eine Umbenennung in object#attribut vorgenommen (nun handelt es sich um eine Variable).
advanced_optimizations-Modus vorgenommenen Veränderungen des Codes können fatale Folgen für die Funktionsweise des Codes haben.this. Denn dadurch, dass einige Objekte nach dem Kompilieren zu Variablen werden, können Fälle auftreten, in denen sich das this nicht mehr auf das Ursprüngliche Objekt bezieht.
Durch die globalen Umbenennungen kommen auch zwei Probleme hinzu, für die es zwar Lösungen gibt, die man aber dennoch bedenken und kennen muss.
Man steht vor einem weiteren Problem wenn man eine Bibliothek schreiben möchte. Dadurch, dass in Bibliotheken (fast) ausschließlich Funktionen bereitgestellt, jedoch selbst nicht verwendet werden, werden diese als unverwendet erkannt und einfach entfernt.
Als Extremfall kann man sich hier eine reine Bibliothek ohne Hilfsfunktionen denken. Diese würde letztendlich im schlimmsten Falle nicht ein Zeichen Code enthalten.
Da diese Restriktionen das Arbeiten mit dem Closure Compiler nahezu unmöglich machen würden, gibt es einige Konzepte, welche die verherendsten Probleme "beheben". Diese werden im nächsten Kapitel "Arbeiten mit den advanced_optimizations" vorgestellt.
| Startseite | Einleitung | Funktionsweise | Verwendung | Kompiliergrade | Arbeiten mit advanced_optimizations | Fazit |
|---|