Jun Inoue
jun.l****@gmail*****
2005年 10月 12日 (水) 04:50:43 JST
On Tue, 11 Oct 2005 23:12:31 +0900 YamaKen <yamak****@bp*****> wrote: > At Tue, 11 Oct 2005 04:06:22 -0700, > jun.l****@gmail***** wrote: > > > > On Mon, 10 Oct 2005 02:53:45 +0900 > > YamaKen <yamak****@bp*****> wrote: > > > > あ、ところで member 変数名は cport より info か desc の方がよいでする。 > > > > > > ScmCPortは抽象portの実体そのものなので、infoやdescといった具象デー > > > タを想起させるような名前は誤解の元だと思います。むしろimplとかに > > > してしまった方がいいかも。 > > > > へ? 実体 = 具象 data じゃないんですか? ScmFilePort は FILE* 持ってるし、 > > ScmStrPort は buffer 持ってるし、もろにその port instance の具象 > > metadata (というか state) を表現する descriptor だと思うんですが。 > > まずい表現でした。「抽象portそのもの」と読み替えてください。info > やdesc(page descriptorのようなものを想定)では内部情報に直接アク > セスする事を示唆しているように取れてしまうので避けたいです。 > > 一方UNIXのfile descriptorのように実体を間接指定するインデックス > と取られるのも面白くないです。ここに収められているのが抽象インタ > フェイスを備えたオブジェクト本体だと明示したいという事です。 それこそ descriptor です。そもそも Unix の "file descriptor" という名前 が間違ってます。実際の table に入ってる構造体こそが descriptor (記述子) であって、何を記述しているかといえば file の interface (Linux だとその stream に責任を負う VFsys の module) の情報です。整数値はただの handle。 と、ここまで書いて「抽象 port の実体」という CPort もおかしくないかと思 い直しました。でもそれならもう ScmPort *port; にしてしまった方がいいです ね。 ScmPortCell というのは実際には名無しの cell さんとしてしか登場せ ず、 accessor 経由で触るだけですから。(つまり ScmPortCell なる構造体は source 中には登場しない) > > ところで encoding 指定は symbol 推奨。case 句に渡せるし、比較 predicate > > が全部効くし、string-append で構築したくなるような事もないでしょう。もし > > あっても symbol-append 作れば済みますし。 > > 数字で始まるコードもあり得るようなので安全側に倒して文字列にしと > いた方がいいと思います。canonicalizeすればいいという意見もあると > 思いますが、canonicalizationの責任はこれより上の層に負わせたいで > す。 上層で canonicalize するならなおさら SigScheme 側では何の名前で用意して もいいのでは? …と思いますが、これ以上机上で議論を交わすのは効率悪そうな ので code を書くのを先決します。…あれ? これって私が書くんですか? (汗) > > > struct ScmFilePort_ { > > > const ScmBytePortVTbl *vptr; > > > > > > FILE *file; > > > }; > > > > ScmStdCharPortVTbl 持っとく必要があります。 > > どういう目的でしょう。ちょっとわからんす。 見間違い。Byte port の table でいいっす。 -- Jun Inoue jun.l****@gmail*****
