Haxe で JSFL を作成する際の注意点
前回の記事にて、自作 JSFL を実行すると Flash CC の JSFL 実行環境がおかしくなってしまう、と記述しました。
Flash CC 13.1 CreateJS・JSFL 出力関連不具合
http://www.dango-itimi.com/blog/archives/2013/001198.html
調査してみたところ、問題箇所と対処策が判明したので以下に記述します。
Haxe から出力される特定のコードが JSFL 実行環境に悪影響を及ぼす
自作 JSFL である FlashToHaxeConveter は Haxe を用いて作成しました。そして、Haxe から出力される javascript 内 以下のコードが、Flash CC の JSFL 実行環境に悪影響を及ぼしていることがわかりました。
String.prototype.__class__ = String; Array.prototype.__class__ = Array;
試しに上記二行のみを記述した jsfl ファイルを作成し、その jsfl を実行後、Flash CC のメニューから「ドキュメント形式を AS3 から HTML Camvas に変換」JSFL コマンドを実行するとエラーが発生します。
Flash CC の JSFL は、実行の度に実行環境が初期化されるような事はなく、以前に実行した JSFL の実行結果が後にまで影響を及ぼすようです。Flash CC を再起動することで、初期化されます。
対策
delete 文を実行し、代入をなかったことにすればエラーが発生しなくなりました。以下の 4行の jsfl ファイルを実行してみると、その後「ドキュメント形式を AS3 から HTML Camvas に変換」コマンドを実行してもエラーは発生しません。(代入式前の String.prototype.__class__, Array.prototype.__class__ の値は undefined であることは確認済みです。)
String.prototype.__class__ = String; Array.prototype.__class__ = Array; delete String.prototype.__class__; delete Array.prototype.__class__;
Haxe から出力される javascript ファイルを見てみると、String.prototype.__class__ と Array.prototype.__class__ への代入処理は JSFL 起動時に実行される事がわかります。よって、Haxe のソースコード内の JSFL 処理終了時に、以下の記述を行えば問題は解決します。
untyped __js__("delete String.prototype.__class__"); untyped __js__("delete Array.prototype.__class__");
実際のソースコードに記述してみた例は以下となります。
https://github.com/siratama/Flash-To-Haxe-Converter/blob/master/main/src/Main.hx
今回の調査では、Haxe の Map クラスを利用する事で String.prototype.__class__, Array.prototype.__class__ への代入式コードが出力される事がわかりました。必ずしも今回の代入式コードが出力されるわけではないので、Haxe で JSFL を作成される方はご注意ください。
JSFL用 Haxe extern
JSFL 用の Haxe extern ライブラリは、以前は lib.haxe.org で公開されていたのですが、内容は古く、Haxe3 になってから現在は非公開状態となってしまっています。現状 JSFL 用 extern は自作する必要がありそうです。
FlashToHaxeConverter 最新版
今回の問題対処を行った FlashToHaxeConverter を github に反映させました。これで FlashToHaxeConverter を実行してもエラーは発生しなくなります。
また、コード内インデントがタブであったりスペースであったりとガタガタになっていたので修正を行い、github 上でソースコードを見やすくしています。
FlashToHaxeConveter
https://github.com/siratama/Flash-To-Haxe-Converter