YamaKen
yamak****@bp*****
2005年 12月 16日 (金) 18:31:13 JST
ヤマケンです。今日も長文投稿の時間がやってきましたよ。 At Fri, 16 Dec 2005 13:29:27 +0900, mover****@hct***** wrote: > > > > まず最初に、'tag'という用語の位置付けが私と食い違っているようで > > > > す。以下のマクロ等で使われている'TAG_VALUE'という語は何を指して > > > > いますか? > > 'tag'という名前は、それがprimaryかextendedかに関係なく型情報の入っ > > ているフィールド全体を指すものとして使っています。 > > > > 太田さんはここで言う'others cdr'をtagと呼んでいるように見えます。 > > そういえば原案ではS->Yをtagと呼んでいたような気もするので誤解を > > 招く命名だったかもしれません。 > 僕の認識とまったく同じです。確かに'tagの上位bitを占めているvalue'というとそうも > 取れますね...。'tagの上のbitを占めている部分'という意味で使ったんですが、曖昧 > でした。 それなら話が進めやすいですね。ではvalueフィールドを指すのに'tag' という言葉を入れるのはやめましょう。tag自身の属性や値を参照して いると誤解されます。 VALUEもちょっと長いし、TAGと長さを揃えてVALと呼ぶのはどうでしょ う。 > > 前のメールで「なんでこれを抽象化しないで複雑な操作するかな」と言っ > > てたのはこの辺です。アクセサ定義のレベルで意識したいのは「value > > フィールドに対して値をget/setする」という事だけで、その詳細の知 > > 識、例えばその型のtagがprimaryかextendedか、GC bitに何をセットす > > べきか等は隠蔽されるべきです。 > 確かにSymbolだけを見れば綺麗です。それは認めます、はい。しかしですよ、String や > CFunc、Pointer、Int等はこの抽象化の範疇に収まりきらず、かなり複雑な操作になっ > てしまいます。結局下の層の中身を見てしまいますよね？ いや綺麗に収まる事を期待しちゃってるんですけど、下の方の層を書い ただけなんで問題を把握できてません。具体例出してもらえますか? それと、単に記述を短かくするのではなく「タグ幅に関係なくvalueを 読み書き」という単純な概念に抽象化する事を重視しているつもりです。 > なので、例外を作ってしまうな > らむしろ層を密に結合させて、結合物を一つの層として見れば良いのでは無いかと思っ > てしまうのですが、どうなんでしょう？この話は compact に限らず、色々な場面で応用 > 可能だと思うので、YamaKenさんの経験上こうした方が良いとか有れば教えて頂きたい > です。 もちろん無理にレイヤやオブジェクトを分割する必要は無いんですが、 このケースについては私が書いてみたような最下層、ビットフィールド の構成情報については当然分離して然るべきものに思えます。 それを行ってない現状のコードは以下のようになっていますが、 #define SCM_TAG_OTHERS_MASK_C_POINTER \ (0x1 | (0x3 << SCM_GCBIT_WIDTH) | (0x7 << 3) | (0x1 << 6)) この定義からは4つのフィールドを連結している事はわかるものの、そ れぞれの意味や関連する定義への手掛かりは全く得られません。また、 開発を進めているうちにあるフィールドのbit幅を広げる必要が出てき たような場合には、細心の注意を払って全関連定義を書き換える必要が あります。元に戻すのも同様です。まとめると、 ・コードから意味が読めない ・変化に弱い ・記述ミスに弱い という弱点があります。これぐらい大した事ない、と感じているからこ のように書いてるんだと思うし、私も若い頃はそういった頭の中で組み 上げる開発をよくやってたんで気持ちはわかるんですが、ちょっとした 事実を思い出してみてください。引数展開機構の無かった頃の SigSchemeのコードがどれだけ繁雑でバグを含んでいたか。また、 SigSchemeのオブジェクト表現を最初からcompactにしようとしてた頃は 設計が大変じゃなかったか。このケースと共通した特徴があるように思 います。 私の実体験からの予想なんですけど、定数に名前を付けてもその実際の 値が頭の中で透けて見えてたりしませんか? 上の例だと SCM_GCBIT_WIDTH が即座に'1'に脳内変換されたりとか。そういう状態 だと抽象的なシンボルは思考を阻害する邪魔物でしかないんですが、そ の思考様式で問題なく扱える設計規模には限界があります。生の値や演 算ではなく、抽象的な概念に立脚してさらにその上に概念を積み上げる 事に慣れないと、記憶力==設計規模に制限されてしまいます。シンボリッ クな抽象概念の先にある実体は意識に上らせないように訓練しましょう。 そうすれば短期記憶の空き容量が増えて一度に扱えるコード量も大きく なります。 とまあ偉そうに経験を語ってみましたが、私が不勉強なだけで世の中に はもっと的確に整理された知識がまとまってるんじゃないかと思います。 問題に直面している時は学習力が高まっていて成長のチャンスなんで色々 読んだり考えたりしてみてください。 私もついでに成長したいので、こういった方面の良書をご存知の方はぜ ひお教えください。 ------------------------------- ヤマケン yamak****@bp*****
