ちゃらんぽらんさんが、拙作 ModuleLoader を紹介してくれた（お願いを聞いていただきありがとうございます）。その記事の補足/コメントをしちゃうぜ。

まず、スクリプティング機能追加（OSAX）に関する以下の記述ですが・・・

...ところで、OSAX ってどうなのでしょうか？・・・中略・・・Mac OS X 以降、個人的にも OSAX は利用しなくなりました。OSAX を利用するなら、代替方法を模索します。さいわいなことに Mac OS X 以降なら代替方法が複数あるのでそれで困らなかったのです。

この姿勢自体は、まったくもって正しいと思います。僕もそうしています。

なんでかというと、OSAX は任意のプロセスにバイナリコードをロードしちゃう技術なんで、いくらかの危険を伴う。だから、避けられるなら避けた方がいいと思う。しかし、当然よい点もあって、その性質を良く見極めて使う必要がある。これは OSAX に限らずどんな技術でも同じ話だ。

OSAX の特性およびそれに伴う良い点/悪い点をまとめてみる。

• AppleScript 言語に用語を追加できる。
  • 良い点 :
    • スクリプティング機能追加のコマンドを素早く呼び出せる。
  • 悪い点 :
    • アプリケーションや他の OSAX の用語と衝突する可能性がある。
• 任意のプロセスにコードをロードできる。
  • 良い点 :
    • 新しいプロセスを起動してプロセスとデータのやり取りをするより、高速に動作する。
    • アプリケーションのハックにも使えちゃう（見方によっては悪い点）。
  • 悪い点 :
    • OSAX 内部でエラーがあったら、その OSAX をロードしているプロセスも巻き添えにしてクラッシュしちゃう。

上の特性から、頻繁に利用して、なおかつパフォーマンスが重要な機能が OSAX とし実装されるべきと考えられます。少なくとも、ModuleLoader に関しては、OSAX として実装される技術だと思います。言語がこのような機能を持っていてもおかしくないのですから。

ModuleLoader 1.x はアプリケーションでしたが、モジュール管理に必要なコードを最小限にする為に OSAX 化しました。この判断は間違っていないと信じます。

次に、「/Library/Scripts 以下から AppleScript Help.scpt を検索」するスクリプトが動かない件ですが・・・僕のところでは動きます。どう動かないか（どんなエラーが起きるかなど）を教えてくれると助かります。

次に、

だから set additional module paths to 命令は一回だけ実行すればよく、ライブラリを場所を変更したときなどに利用します。この命令で追加したパスは上書きはできますが、削除はできません。削除するには Scriptfactory.ModuleLoader.plist を削除するしかないようです。

ですが、わざわざ Scriptfactory.ModuleLoader.plist を削除しなくても、

で削除できますよ。

次に、

ところで...ModuleLoader.osax の特徴としてモジュールの自動的なアップデートとあるのですが...。次のようなスクリプトで Value.scpt をいくら変更しても自動的にアップデートしないのですが、load module 命令ではアップデートしないのでしょうか？

の件ですが、ModueLoader のマニュアルの中での「自動的なアップデート」とはモジュールをロードする際に、そのロードされるモジュールが依存しているモジュールをアップデートします、という意味です。スクリプトの実行の度にモジュールをアップデートしたかったら次のようにするのがおすすめです。

load module コマンドは、ModuleLoader のおまけみたいな物です。module コマンドと boot (module loader) for me の一文に、ModuleLoader の真価があります。上記のコードは、ちゃらんぽらんさんの今後の解説で理解できるようになると期待しています。