未実装でも大丈夫でしょ。Packages.java;Java依存の他に、Rhino依存のコードもあるので、実際に動かしながら調べてわかった関数定義。環境によってはいらないものもある。指定パスのスクリプトをロードする。実行環境のホストオブジェクトが同等の機能をもってないとしんどい。読み込んでグローバル空間へ適用。やって差し込まれたスクリプトから別にload()されるとお手上げ。コンソールへのメッセージ出力。SpiderMonkeyとかは定義しなくてよいかな。これは特殊な用途で呼び出されてる。fileNameプロパティを持つ例外をスローする。}fail()だが、これはJsDoc.jsが自分自身のパスを取得するために使用している。具体的には、JsDoc.jsの1008~1009行目で、キャッチした例外のfileNameプロパティがJsDoc.js自身のパスを返すことを期待して使ってる。ご本人もコメントに書いてるように、もうちょっとなんとかしたほうがよい使い方だな。これだけじゃないっすこれでどうよ?と、思ったがエラーがでる。Array#filterメソッドとやらを使ってやがる。JScriptなどの場合は以下の要領で拡張。result;}さて、これでどうだ!と思ったが、今度はテンプレートスクリプト側でエラーが発生。テンプレートにHTMLを指定した場合はまだ追っかけきれてないが、XMLを指定した場合は、テンプレート中でFunction#getParam()とかいうメソッドで引っかかる。冒頭で述べたとおり、今回の調査ではスクリプトの動的ロードをなんとかするためにhtaにした。メインスクリプトのJsDoc.js自体も即時実行コードになるため、それ自体も動的ロードで実行させるようにしていた。これでなにが問題か、というと、JsDoc.jsの処理中にJsPlate.jsを「load()」しにいくが、このロード結果が現在実行中の空間にはまだ反映されないのだ。プラグインロードはしないと割り切って先にJsPlate.jsをタグでロードしておくようにする必要があった。プラグインロードまで見越すとなると、JsDoc.jsの最終の2行をコメントアウトして先にロードしておき、イベントハンドラなどから同様の実行コードを実行するように改変する必要がある。Rhino環境ではどうかわからないが、JsDoc.jsの1071行目から定義されている「ReadFile」関数が値を返さない実装になっている点も注意。これ、ほんとに動作するのか?あと、for-inループに依存しすぎてるので、ことによるとfor-in内でメンバの除外処理が必要になるかも。最低限Array#filterは実装しなきゃなんないからね。まとめ外部依存の洗い出しは大方できたが、JScript系の実行環境で使用するのは厳しそう。SpiderMonkeyとかJSDBならなんとかできる可能性アリ。根性が残ってたら続けるかも。吊ブックマークレットtumblrのキーボードショートカットが便利になっとる。Chrome編dataスキームの画像をブロックしてみるローカルストレージを確認したり消したりするブックマークレットそうそう、いまさらTwitter始めました。(9)このブログについてJavaScriptとかC#とかPHPとか。