#includeのパスの解決について

  1. 初めまして。
    今まで"My Macros"直下のマクロばかり実行していたので気づかなかったのですが、#includeについて。
    My Macros
    ├XXX
    │├test2.js
    │├called2.js
    │└called1.js
    └test1.js

    test1.js
    #include "XXX/called1.js"
    x();

    test2.js
    #include "called1.js"
    x();

    called1.js
    #include "called2.js"

    called2.js
    function x(){alert(1);}

    test1.jsは失敗し、test2.jsは成功します。
    実行したマクロファイルからの相対パスになっている様ですね。
    今回イベントマクロを"My Macros/Events"フォルダに入れて使おうとして、「ファイルが見つかりません」ダイアログが無限ループして気づきました。"My Macros"あたりからの相対パスにできないでしょうか。

     |  黄身  |  返信
  2. はじめまして。Mery をご愛用くださりありがとうございます。

    > 実行したマクロファイルからの相対パスになっている様ですね。

    そうですね。
    現在の仕様では include のパスは "実行した" マクロファイルからの相対パスになっています。つまり include したマクロファイルからさらに include する時のパスは "実行した" マクロファイルからの相対パスで指定することになります。

    called1.js
    #include ""XXX/called2.js"

    と指定してやる必要があります。これはすごくわかりづらいですね…
    下の階層の called1.js と called2.js が同じフォルダ内にあるのだから黄身さんの例の通り指定してやるのが自然な気がします。

    > "My Macros"あたりからの相対パスにできないでしょうか。

    called1.js から include するときに "My Macros" からの相対パスだと "XXX/called2.js" となり、結果的に同じで分かりづらいような気がしますが…

    黄身さんの例の通りの記述方法、つまり "実行した" マクロファイルからの相対パスではなく、include 元のファイルからの相対パスで行けるようにした方が分かりやすいと思うのですがいかがでしょうか?

    ----

    既存のマクロへの影響も考えられますので、他の方のご意見も伺いたいところです。

    仕様変更するとして、下記のようなイメージになりますがどうでしょう。include で階層的に使われている方がいらっしゃいましたらご意見をいただけると助かります。

    My Macros
    ├XXX
    │├test2.js
    │├called2.js
    │└called1.js
    └test1.js

    test1.js
    #include "XXX/called1.js" ← include 元である test1.js からの相対パス
    x();

    test2.js
    #include "called1.js" ← include 元である test2.js からの相対パス
    x();

    called1.js
    #include "called2.js" ← include 元である called1.js からの相対パス

    called2.js
    function x(){alert(1);}

     |  Kuro  |  返信
  3. > called1.js から include するときに "My Macros" からの相対パスだと "XXX/called2.js" となり、結果的に同じで分かりづらいような気がしますが…

    > 黄身さんの例の通りの記述方法、つまり "実行した" マクロファイルからの相対パスではなく、include 元のファイルからの相対パスで行けるようにした方が分かりやすいと思うのですがいかがでしょうか?

    指定方法はどちらでもいいと思います。
    私が意図していたのは分かりやすさというよりも、一つのファイルをどこからでも使えた方がいいということなんです。
    例えばksさんのincludeライブラリを導入するにしても、実行ファイルのパスに合わせていくつもコピーが必要になります。これは非常に無駄だと思うんです。

     |  黄身  |  返信
  4. > 例えばksさんのincludeライブラリを導入するにしても、実行ファイルのパスに合わせていくつもコピーが必要になります。これは非常に無駄だと思うんです。

    なるほど、そういうことでしたか。

    実行元のファイルを My Macros 直下ではなく下層のフォルダに格納してしまうと、例えば ks さんの include ライブラリですと HTTP.js などの内部で #include "include/IO.js" とされている部分が動かなくなってしまうわけですね。

    それを回避するには include ライブラリごと実行ファイルと同じフォルダにコピーしなきゃならない。確かに大変無駄な気がします。

    #include 元のファイルからの相対パスにすれば実行元のファイルがどこにあろうとも関係なく include ライブラリは一つの場所に置いておけば動きそうですね。

    プログラミング言語でも include のように外部ファイルを呼び出すときは呼び出し元のファイルからの相対パスとなっていることが多いですし、この仕様に変更したいところです。

    ただ、この仕様変更を行うと ks さんの include ライブラリ内で各ファイルに指定されている #include のパス (#include "include/IO.js" など) を相対パス (#include "IO.js") に修正する必要がでてきます。あと、include ライブラリを使用されている人はのきなみマクロが動作しなくなるという…

    プログラムの修正は完了しましたが、影響範囲を考えるとなかなかゴーしづらいところですね… うーむ、どうしましょう。

     |  Kuro  |  返信
  5. 呼ばれた気がしました

    黄身さん,初めまして.
    Wiki の個人ページ更新を見て「何か凄い人キター」とわくわくしながら見ていました.

    で本題ですが,
    #include が最初に実行されたマクロからの相対パスになっている件は,私も若干気にはなっていました.
    ただ私はマクロを全て My Macros の直下に置く運用にしていたので流していました.
    現行仕様だと include ライブラリが複数必要になってしまう件は確かに問題でして,
    ちょくちょく機能追加やバグ修正しているのでその度に全部更新をかけるのは少し無理があります.

    黄身さんの仰る My Macros からの相対パスは,include ライブラリ的には一番都合が良い解決方法です.
    そこに置いておけば,どこに置いたマクロからでも参照できるので.
    一方の Kuro さんの仰る案だと,IO.js が参照している MeryInfo.js に include/ をつけなくても良い,という点で自然な動きだと思います.

    勝手な希望では,今の IO.Include が採用している動きなのですが,いくつかの候補で一番最初に見つかったのが読み込まれる,というのが理想だと思います.
    IO.Include では「My Macros からの相対パス(黄身さん案)」「読み込み元からの相対パス(Kuro さん案)」「最初に実行されたマクロからの相対パス(現行)」の順にファイルを探して,最初に見つかったファイルを読み込みます.
    DLL の読み込みと似たような動きです.
    これだと今あるマクロとの互換性もとれるので,多くの場合問題にならないのではないでしょうか.

    一番の問題は実装が一番面倒なことですが……

     |  ks  |  返信
  6. ks さん、助言ありがとうございます。来てくださることを期待してましたw

    > Wiki の個人ページ更新

    Wiki を作っておきながら個人ページという機能があることを知りませんでした^^;
    ほんとですね、なんか凄いッ!

    > IO.Include

    ソースを拝見しました。なるほど!多段作戦、ありですね。
    そもそも「My Macros」フォルダが Mery フォルダの配下にあるっていうことを忘れていました (汗

    私は自作のマクロは「マイドキュメント/My Macros」というフォルダに保存しており「My Macros」フォルダの場所って人それぞれだから、そこからの相対パスと言われても… と思っていましたが Mery 配下にある 「My Macros」フォルダだけは特別でパスが通ってるよ。みたいな感覚にすれば良いのですね。

    > 一番の問題は実装が一番面倒なことですが……

    うーむ、ちょっと面倒そうですがやってみます。

     |  Kuro  |  返信