Kazuki Ohta
mover****@hct*****
2005年 11月 3日 (木) 12:25:26 JST
おはようございます。太田です。 > r1949でdata.cがいくつかのファイルに分割されましたが、いくつか変 > 更した方がいい点があります。 > > まず最初に、今回のようにファイルを分割する場合は一旦元のファイル > からsvn cpしてそれからコードを削るようにしましょう。リポジトリ上 > で元ファイルとの連続性を保つためです。この必要性を理解するには > trunkで以下のような操作を行ってみてください。 なるほど、分かりました。 > 話の前提として、将来的にstorage層の実装を目的と環境に応じて自由 > に挿し替えられるようにしたいという要求があります(CDR-coding等)。 > 最初からあれこれ要求しすぎて開発が滞るのを避けるため表だった主張 > はしてきませんでしたが、uimの土台として適切な仕様になるように設 > 計とコードに干渉してきました。そろそろコードもまとまってきたので > 徐々に目標等を明示してゆこうと思います。 ふむ、そこ踏み違えてました。僕はgc.cのみを差し替え可能にしておけば異な る実装を持ってこれると思っていました。 つまり、datas.c <=> gc.c <=> symbol.c <=> constant.cが並列した概念を 持つファイルとして考えていました。なのでSigScheme_Initialize_internalに symbol, constantの初期化が移動しています。 この点を明示するためにも、以下のようにファイル名を分離するのは如何がで しょうか？親子関係がはっきりして良いと思うのですが。 - storage.c - storage-gc.c - storage-symbol.c - storage-continuation.c > ・今まで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層に委譲するべきで > す。 という訳で初期化順がstorage層によって違うというのは考えてませんでした。 fixします。 > ・定数の初期化をconstants.cに分割するのはやりすぎかつ無意味です。 > ファイルを分割する事で得られるメリットには実装の隠蔽とファイル > 単位での実装の挿し替えがありますが、定数の実装はScmObjと > ScmCellの表現によりほぼ自動的に決まってしまうので、挿し替え単 > 位としてはScm_NewInt()等と同じファイル(datas.c)に集約するのが > 合理的。さらにdatas.c内の関数は即値とcellの区別等の内部表現を > 知っている事を前提にしているのだから、それに依存した定数表現を > 隔離して隠す事も無意味。 Compactは今は一応headerのみが出来ていますが、定数初期化とgc部分 を作りなおす必要があります。なので定数部分を分離しておきたかったという のが主な動機です。あれだけ多数の変数がUSE_COMPACTフラグで切替え られているのは気持ち悪い気がしました。まぁあれぐらい大丈夫なのかもしれ ないので、一応data.cに統合という事で。 > ついでに、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()は残しておいてください。コード整理に当たって > 必要な情報になるので。 分離より先に統合してしまいます。ちょっとこれ以上USE_フラグが増えるのは気 持ち悪い... > ・上記の整理が終わったらdatas.cはかねて言っていたように改名して > しまいましょう。私はstorage.cがいいと思いますがどうでしょう? > SigScm_InitStorage() のコメントに "FIXME: should be renamed?" > とありますが、他の案があるんでしょうか。 一番上に書いた理由からStorage <=> Symbol <=> GCは並立した概念だと 考えていたので、このように分離した後のdatas.cの機能をみるとStorageという 単語は当てはまらないように思いました。 ------------------------------------------------- Kazuki Ohta : mover****@hct***** -------------------------------------------------
