ちょい間が空きました
仕事で帰りが遅くなり、かつ、なんというかストレスフルな状態だと、ついつい飲んで帰っちゃうので…
それはさておき。
Diksamで、いつまでも1行目に
int print(string str);
とか書いてるのもアレなので、ソースファイルを分割する方法について考えてみる。
require
今考えているのは、ソースファイル冒頭で
require hoge;
と書くと、hoge.dkmが読み込まれる、という方法。
Diksamは、「慣れているのが一番だよね」とばかりにCなりJavaなりからそっくり文法を取り込んでいますが、予約語がincludeでもimportでもなくrequireなのは、やっぱり意味が違うと思っているから。
前にも書いたように私はヘッダファイルって捨てたもんじゃないと思っていますが、Cの#includeのように、「該当箇所にプリプロセッサが別ファイルを埋め込む」ってのは、今時の言語としてはさすがにあんまりだと思っている。「ヘッダファイル末尾のプロトタイプ宣言でセミコロン付け忘れた」なんて場合、コンパイルエラーがその場で出ずにひどい目にあったりしますし。ということで、Diksamのrequireは、そこにソースを埋め込むのではなく、別途コンパイルして、そのファイルにある関数とかを使えるようにするものです。よって「取り込む(include)」するわけではないのでincludeはおかしい。
また、Javaのimportは、「foo.bar.Hogeと書く代わりにHogeと書ける」というものでしかありません。Diksamではrequireしなければそこにある関数とかはそもそも使えないのでこれも違う。
ダイナミックロード
requireされるファイルの中には、関数のソースが丸ごと書いてあってもよいですが、
int print(string str);
みたいなプロトタイプ宣言だけでもコンパイルは通ります。
で、いざ該当関数が呼ばれたときは、printの場合ネイティブ関数なのでそのまま使えますが、ネイティブ関数にも既ロードの関数でもなかったら、ダイナミックロードにしたいなあ、と思っています。
名前空間
Javaみたいに、各ソースの冒頭に
package com.kmaebashi.util.hoge;
とか書かせるのは、Javaではフォルダ階層がパッケージ階層と一致していることを考えると冗長な気がする。
ましてC++やC#のようにnamespaceでインデントひとつ食っちまうのはもっといや。現実的に、複数の名前空間を1ソースに入れることなんてないんだから。
require時に
require diksam::io::stdio;
とか書くと、DKM_REQUIRE_PATHで指定されたディレクトリから「diksam/io」をほじくった部分の「stdio.dkm」というファイルを読み込むようにして、そうするとstdio.dkmで定義されている関数や変数はdiksam::io::stdio名前空間内にあるとみなされるというのはどうか。
