既に忘れ去られているような気もしますが、Diksamは一応細々と作業を進めていました。先日、
*1:…には見えないかもしれませんが、一応遅々として進んではいるのでそのうち公開します。ええと、遅くとも連休明けには。
なんてことを書いてしまったのもありますので、バグは多々ありそうですが、ひとまず暫定公開します。
UNIX版:
http://kmaebashi.com/programmer/devlang/diksam_unix_20080512.tgz
Windows版:
http://kmaebashi.com/programmer/devlang/diksam_win_20080512.tgz
言語仕様の大きな修正は以下のとおりです。
分割コンパイルを導入しました
私はCのヘッダファイルという概念が大好きな人間なので、Diksamにも同様の概念を取り込みました。
ソースファイル冒頭で、
require hoge;
と書くことで、hoge.dkhというファイルを取り込みます。通常のDiksamのソースの拡張子は.dkmですから、拡張子が異なります。
.dkhファイルには、関数のプロトタイプ宣言や、interfaceの宣言(後述)を記述します。
ここで、hogeはパッケージ名です。パッケージ名は、ディレクトリのパスと、拡張子を除くファイル名から構成されます。
.dkhファイルには関数のプロトタイプ宣言しか書かれていませんが、関数が実際に呼び出された際には、その関数の本体がダイナミックロードされます。hoge.dkhでプロトタイプ宣言されている関数の本体は、hoge.dkmになければなりません。
hoge.dkhを検索するときのパスは、環境変数DKM_REQUIRE_SEARCH_PATHで指定します。ダイナミックロード時のパスはDKM_LOAD_SEARCH_PATHを使用します。この環境変数に、UNIXなら:, Windowsなら;でパスを区切って指定します。これを分離しているのは、「テスト時にはスタブを使い、本番では本物のライブラリをリンクする」という使い方を想定しているためです。
現状で、Diksamで使える唯一のライブラリである「print()」は、diksam.langというパッケージに存在します。よって、diksamというディレクトリを彫った上でそこにlang.dkm(同梱しています)を格納し、diksamのひとつ上のディレクトリにDKM_REQUIRE_SEARCH_PATHを通さなければなりません。
このおかげで、crowbar, Diksamと続いた「実行形式単体で実行できる」という利点は失われています。そのうちcrowbarで実装したビルトインスクリプトを導入する予定です。
クラスを導入しました
クラスとインタフェースを導入しました。特徴は下記のとおり。
- メンバの参照にはthis. が強制される
- メンバのアクセス修飾子として、pubilc, private はあるが、protected は存在しない
- コンストラクタにはconstructor 修飾子を付加する
- メソッドのデフォルトはnon virtual
- オーバーライドする側にoverride の指定が必要
- 継承は「:」で行なう
- コンストラクタも継承され、オーバーライドも可能である
- abstract なクラス以外は継承できない
ひとまず今はサンプルソースを示すにとどめます。
// printを使うにはこのrequireが必要。 require diksam.lang; // interfaceの宣言。 interface Printable { void print(); } // クラスの宣言。 class Point : Printable { double x; double y; // overrideするときには常にoverrideの指定が必要。 override void print() { println("x.." + this.x + ", y.." + this.y); } // コンストラクタには、型名の代わりに「constructor」を指定する。 constructor initialize(double x, double y) { this.x = x; this.y = y; } } Printable printable = new Point(10, 20); // インタフェースのメソッドが呼び出せる例。 printable.print();
いろいろ不備はあると思いますので、見つけられましたらご報告お願いします(他力本願……のつもりはないのですが)
――いやまあなんというか、やっぱり開発はインクリメンタルにやらないとダメですね。