Ich habe festgestellt, dass der Google Closure-Compiler document nicht in so etwas wie d umbenannt hat, um Speicherplatz zu sparen.
Ich kann mir keinen Fall vorstellen, in dem dies den Code sprengen würde (dh wo document auf etwas anderes deutet). Das Gleiche gilt auch für window .
Gibt es einen Grund dafür, document auf diese Weise zu schützen?
== EDIT ==
Indem ich es umbenannte, dachte ich darüber nach, es neu zuzuweisen. Beispiel unten.
%Vor%ProblemFactory ist richtig.
Dies ist ein //TODO im Compiler-Quellcode. Wenn wir document und window nicht beibehalten haben und sie stattdessen mit d zum Beispiel ausgeführt haben, weiß der Closing-Compiler im Moment nicht, ob er eine globale Datei aus einer anderen Datei überschreibt. Wie die Kommentare sagen, wird dies in der Zukunft an diesem Punkt gelöst werden.
Wenn wir den Quellcode des Abschlusscompilers in VariableReferenceCheck.java können wir folgendes finden:
Wenn wir den Hot-Button überprüfen -Swap-Algorithmus selbst können wir das sehen:
%Vor%So können wir sehen, dass dies nur der Abschlusscompiler ist, der den Code von Globals über mehrere Dateien hinweg nicht gut genug versteht, um diesen Ersatz zu machen. Sie können den Ersatz immer selbst vornehmen:)
Der Closure-Compiler führt diese "Optimierung" standardmäßig nicht aus, weil er eine größere Quelle erzeugt, wenn verwendet mit gzip . Sie können diese Optimierung aktivieren, indem Sie den AliasExternals pass mit der Java-API oder einem benutzerdefinierten Build aktivieren.
Siehe Ссылка
Ich denke, document ist eine standardisierte, immer globale Variable. Um den gleichen Weg d zu verwenden, muss es auch global sein, daher wird der globale Namespace eine andere "Junk" -Variable haben.
Es könnte für nicht bewusste Entwickler gefährlich sein (was nicht bewusst ist, also ist es keine Standardvariable).
Tags und Links javascript google-closure-compiler