スレッドメモ

◆ [fj][fj.os.linux] MIME Subject / 生JIS Subject (Re: 環境変数の定義)

<030806134451.M0108028@ns.kobe1995.net> NAKAMURA Kazushi (8/6)

そして何故Subject限定？まさか、MIME拡張を義務だとか勘違いしているんじゃないでしょうね。MIMEはあくまで拡張仕様で、そもそもヘッダに使うべき物ではなく、本文に平テキスト以外のマルチメディア情報をエンコードして流せるようにするための拡張です。マルチメディア情報でもない、平テキストは当然、平テキスト（生JIS)で流すのが本来の姿です。最近になってMIME拡張で流して「も」構わないようになりましたが。MIMEエンコードしてしまうと、MIME拡張に対応したソフトウェアでしか読めなくなってしまいます。それに対し「生JIS」は、どんなソフトウェアでも読めますし、また読めるように作らなければ(must)なりません。

<030806182343.M01294817@ims.ipc.kit.ac.jp> Tsukamoto Chiaki (8/6)

ということで, Subject: は生JISにするままで,

Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp

の二行を header に入れておくのではどうでしょうか.

<bgr4mi$dp0$1@nsvn01.zaq.ne.jp> Takashi SHIRAI (8/6)

私自身は、母国語の「文字」を「画像」とか「音声」とかと一緒くたにされるのがどうにも鼻持ちならないので、敢えて Subject:の MIME encode はしないようにしています。

◆ [XP-jp] 責務，変更，シンプル (was Re: 「 An ExtremePro) grammingEpisode 」の翻訳版を

[04584] Akira Kawamata (8/14)

素朴な疑問なのですが。

達成すべき目標が早いペースで変化していくプロジェクトでは、自然なプログラムを書いても、結果として不自然になってしまうということは無いのでしょうか?

[04586] Hidehiko AKASAKA (8/14)

XPでは今分かっているものを、シンプルに実現することに注力する訳ですけど、

　シンプル ≒ 自然な役割分担

と考えてよいのだとうと思います。

[04594] Akira Kawamata (8/15)

そういう意味で、チームによる共同作業の目標として、「シンプル」は目標にできるけれど、「自然な役割分担」は難しいような気がします。

[04605] Kenji HIRANABE (8/16)

なるほど．「シンプル」がより「現実的な」基準ということですね．賛成です．

また，どちらの場合でも，「名前」に注目するとその分割，分担が良いかどうか，が見えるというケースが多いと思っています．

「テスト可能性」と「変更に対する追随性」でもって，うまくオブジェクト指向的な「よい設計」を再定義できる気がしています．

old: よい Separation of Concerns ＝ 自然な責務分割　＋　強い凝集度　＋　弱いカプリング

new: よい Separation of Concerns ＝ 変更を伝播させない分割 + テスト可能な分割

[04608] Hidehiko AKASAKA (8/16)

「シンプル」で、かつ「自然な役割ではない」

というケースを想定できないということです。

[04609] Kenji HIRANABE (8/16)

以前，Kent Beck に矢崎さんが果敢に試みた有名な質問があります．

「ユーザ情報」クラスに「電話番号」がある場合電話クラスを作りますか？

◆ [fj][fj.comp.lang.c] 構造体のメンバの記憶域の順

<871xve8046.wl@anago2.mas.chi.its.hiroshima-cu.ac.jp> Fujii Hironori (8/22)

構造体のメンバの記憶域は並べられた順に割り当てらることとなっていますが、これには何か理由がありますか。

<squ7k56vv9z.fsf@stellar.co.jp> Hideo "Sir MaNMOS" Morishita (8/22)

ならびが保証されていないと、むっちゃ困りますけど、理解できません？

<bi586t$i2n$1@ns.src.ricoh.co.jp> Junn Ohta (8/22)

のように構造体を宣言しておいて、任意の長さの領域をmalloc()してからstruct foo *にキャストして使うなんてことをむかしのプログラムはよくやってました。つまりsに任意の長さの領域を割り当てたいからです。

処理系がメンバーの割り当て順序を自由に変更してよいことになったら、この手のプログラムは動かなくなる可能性がありますね。

<YAS.03Aug23012402@kirk.is.tsukuba.ac.jp> Yasushi Shinjo (8/23)

はい。ハードウェアのレジスタを叩く時に、書いた通りの順番でないと困るからです。Ｃ言語はＯＳのカーネルを記述するために作られた言語なので。

<bi73b2$u5m$1@bluegill.lbm.go.jp> toda (8/23)

「並び順による照合」を前提に考えれば、コンパイラが勝手に順番を変えたら困ることは自明ですよね。