YamaKen
yamak****@bp*****
2005年 11月 3日 (木) 10:54:14 JST
ヤマケンです。
太田さん、SigSchemeの整理おつかれさまです。
r1949でdata.cがいくつかのファイルに分割されましたが、いくつか変
更した方がいい点があります。
まず最初に、今回のようにファイルを分割する場合は一旦元のファイル
からsvn cpしてそれからコードを削るようにしましょう。リポジトリ上
で元ファイルとの連続性を保つためです。この必要性を理解するには
trunkで以下のような操作を行ってみてください。
svn log uim/uim-internal.h
svn diff -r10:100 uim/uim-internal.h
というわけで、r1949で追加されたファイルは一旦消してsvn cpしてか
ら改めて変更をcommitしてください。
#ちなみに、svn diffがファイルのrenameを越えて動作するようになっ
#たのは今気付きました orz いつから?
話の前提として、将来的にstorage層の実装を目的と環境に応じて自由
に挿し替えられるようにしたいという要求があります(CDR-coding等)。
最初からあれこれ要求しすぎて開発が滞るのを避けるため表だった主張
はしてきませんでしたが、uimの土台として適切な仕様になるように設
計とコードに干渉してきました。そろそろコードもまとまってきたので
徐々に目標等を明示してゆこうと思います。
・今までScm_InitStorage()で行っていた各種初期化が
SigScm_Initialize_internal()に移動してますが、これはまずいです。
定数とGC等の初期化順はstorage層の実装によって異なるからです。
例えば定数がheap内に割り当てられる実装ではInitStorage()後に
InitConstants()しなければいけないし、逆にheap等の初期化に
SCM_NULLを必要とする実装では先に初期化しておかないといけません。
SigScm_InitConstants();
SigScm_InitGC();
SigScm_InitSymbol();
SigScm_InitStorage();
SigScm_Initialize_internal()の中ではSigScm_InitStorage()だけを
呼ぶようにして、各部の初期化の責任はstorage層に委譲するべきで
す。
・定数の初期化をconstants.cに分割するのはやりすぎかつ無意味です。
ファイルを分割する事で得られるメリットには実装の隠蔽とファイル
単位での実装の挿し替えがありますが、定数の実装はScmObjと
ScmCellの表現によりほぼ自動的に決まってしまうので、挿し替え単
位としてはScm_NewInt()等と同じファイル(datas.c)に集約するのが
合理的。さらにdatas.c内の関数は即値とcellの区別等の内部表現を
知っている事を前提にしているのだから、それに依存した定数表現を
隔離して隠す事も無意味。
ついでに、SigScm_InitConstants()の中でSigScm_GC_Protect()が呼
ばれているけどこれはillegalなのでGC初期化後に呼ぶようにしない
といけない。よって特定のstorage実装への依存が発生しているわけ
で、この点からも定数を別ファイルに分離する意味はありません。
datas.cに集約しましょう。
・continuationとdynamic extentはcontinuation.cという名前で分割し
て構いません。今後別実装が現れる事も考えて
continuation-longjmp.cとかでどうでしょう。
・ちょっと本筋から外れますが、portの実装はSCM_USE_NEWPORTの方に
統一してしまっていいでしょうか? 機能的には旧実装に追い付いてい
るし基本動作にも問題はないんですが、太田さんが未踏に提出するコー
ドの安定性を損なう可能性を考えて選択可能にしてありました。消し
て良ければdatas.cもスッキリします。もし消す場合も
SCM_PORT_UNGETC()は残しておいてください。コード整理に当たって
必要な情報になるので。
・上記の整理が終わったらdatas.cはかねて言っていたように改名して
しまいましょう。私はstorage.cがいいと思いますがどうでしょう?
SigScm_InitStorage() のコメントに "FIXME: should be renamed?"
とありますが、他の案があるんでしょうか。
-------------------------------
ヤマケン yamak****@bp*****