YamaKen
yamak****@bp*****
2005年 11月 3日 (木) 15:01:00 JST
At Thu, 3 Nov 2005 12:25:26 +0900, mover****@hct***** wrote: > > 話の前提として、将来的にstorage層の実装を目的と環境に応じて自由 > > に挿し替えられるようにしたいという要求があります(CDR-coding等)。 > ふむ、そこ踏み違えてました。僕は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 そうですね。その方が概念的にスッキリしますね。 将来的に代替実装のファイルが増えてきたら何らかの階層化を行ってディ レクトリを分けた方がいいかもしれませんが、現時点では要求がはっき りしないので storage- プリフィクスにしといた方がいいですね。 rename越えのsvn diffができる事がわかったので積極的に再構成する事 にしましょう。 > > ・定数の初期化をconstants.cに分割するのはやりすぎかつ無意味です。 > Compactは今は一応headerのみが出来ていますが、定数初期化とgc部分 > を作りなおす必要があります。なので定数部分を分離しておきたかったという > のが主な動機です。あれだけ多数の変数がUSE_COMPACTフラグで切替え > られているのは気持ち悪い気がしました。まぁあれぐらい大丈夫なのかもしれ > ないので、一応data.cに統合という事で。 そういう意図でしたか。それならむしろdatas.c自体をcompactと通常版 に分けた方がいいんじゃないかと思います。両者間で共有可能なcell型 のオブジェクトの初期化コード(Scm_NewString()等)を別ファイルに分 離して。 > > ・ちょっと本筋から外れますが、portの実装はSCM_USE_NEWPORTの方に > > 統一してしまっていいでしょうか? 機能的には旧実装に追い付いてい > > るし基本動作にも問題はないんですが、太田さんが未踏に提出するコー > > ドの安定性を損なう可能性を考えて選択可能にしてありました。消し > > て良ければdatas.cもスッキリします。もし消す場合も > > SCM_PORT_UNGETC()は残しておいてください。コード整理に当たって > > 必要な情報になるので。 > 分離より先に統合してしまいます。ちょっとこれ以上USE_フラグが増えるのは気 > 持ち悪い... 了解っす。マルチバイト文字のサポートのためにも統合しちゃった方が 楽ですしね。 今やっちゃっていいですか? それともファイル構成整理と一緒にお願い しちゃっていいでしょうか。 ------------------------------- ヤマケン yamak****@bp*****
