最近、Google Closure Compiler を調べています。.jar ファイルをダウンロードして、テストドライブを提供しました。これまでのところ、私は非常に感銘を受けたと言わざるを得ません。最小化を超えたその有用性は確かにわかります。Google チームへの小道具!
ただし、小さな不満が 1 つあります。最適化に関する限り、2 つのオプションしか得られないように思えます。SIMPLE_OPTIMIZATIONS または ADVANCED_OPTIMIZATIONS のいずれかです。前者は十分ですが、非常に単純です。1 つには、何かが欠けていない限り、すべてのプロパティ名は変更されません。また、到達不能コードは削除されません。一方、後者のオプションは破壊的すぎます。
現在、私は JavaScript にかなり慣れていないため、何かが欠けている可能性が非常に高いです。私がばかげたことを言ったら、遠慮なく私に教えてください。そうは言っても、JavaScript での名前変更の問題は理解できます。Google チームは、ドット表記 (object.property) の代わりにブラケット表記 (object['property']) を使用して、変更したくないプロパティにアクセスし、2 つの使用方法を混在させないことをお勧めします。また、次のパターンを使用して「エクスポート」する方法も提案しています。
MyClass = function(name) {
this.myName = name;
};
MyClass.prototype.myMethod = function() {
alert(this.myName);
};
window['MyClass'] = MyClass; // <-- Constructor
MyClass.prototype['myMethod'] = MyClass.prototype.myMethod;
ただし、2 つの表記法を混在させたい正当なケースもあります。ゲームを構築しているとしましょう。ゲームのコードは、クロージャ内で完全に分離されています。グローバルスコープには何も「エクスポート」しませんし、その必要もありません。実際、window オブジェクトに触れるべきではありません。ただし、XML 構成ファイルからいくつかのゲーム内プロパティを読み取る必要があります。
サンプル JavaScript:
var TheGreatAdventure = (function(window) {
function Fighter() {
// Private to application
this.id = 42;
// Accessible to XML configuration system
this.name = 'Generic Jen';
this.hitPoints = 100;
this.onAttack = genericFighterAttack;
this.onSpeak = genericFighterSpeak;
...
}
Fighter.publishedProperties = ['name', 'hitPoints', 'onAttack', 'onSpeak']
function genericFighterAttack() {...}
function genericFighterSpeak() {...}
function cassieAttack() {...}
function cassieSpeak() {...}
...
EntityReader = {
...
function readFromXMLNode(attributes, entityClass, entityInstance) {
for (var i = 0; i < attributes.length; i++) {
var attribute = attributes[i];
if (attribute.nodeName in entityClass.publishedProperties)
entityInstance[attribute.nodeName] = bindContext[attribute.value];
}
}
...
}
}(window));
サンプル XML 構成ファイル:
<Fighter name='Custom Cassie' onAttack='cassieAttack' onSpeak='cassieSpeak'/>
上記のシステムはプロパティの割り当てに失敗するだけでなく、関数 cassieAttack と cassieSpeak はデッド コードとして最小化中に削除されます!
さて、ゲームのコード全体でブラケット表記を使用して、「公開された」プロパティのすべてにアクセスする方法はありません。そうすることで実行時のペナルティがなくても (何もあるべきではありません)、余分なタイピングが依然として多く含まれており、(IMO) 目障りです。このような共通のプロパティを使用すると、すべてがテキスト エディター内の文字列として表示され、構文の強調表示の目的が無効になります。
これらのプロパティに対する単純な @preserve (または同様の) ディレクティブを使用すると、ADVANCED_OPTIMIZATIONS を最終的なプログラム サイズの最小コストで使用できるようになります。何か不足していますか?