YamaKen
yamak****@bp*****
2005年 10月 11日 (火) 23:12:31 JST
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のように実体を間接指定するインデックス と取られるのも面白くないです。ここに収められているのが抽象インタ フェイスを備えたオブジェクト本体だと明示したいという事です。 > > というわけで、以下のような2段構成はどうでしょうか? この場合上記 > > の例はScmStdCharPortのrbufが溜まるまでbyte_readp()を繰り返す事で > > 実現できます。 > > そうですね…双方向 multibyte port ができないかと色気を出してたんですが、 > 無理なのでそれで行きましょう。 インタフェイスとしては単一storageへのread/writeを仮定するわけで はないのでOKだと思います。pipeやsocketは双方向で何も問題ないです。 > ただし rbuf/wbuf は区別する意味がありませ > ん。SigScheme 側から write-char するなら必ず文字単位で data が提供される > し、 そうでした。何考えてたんだろ。 > write-byte したときはそもそも文字が完成する事が期待できません。そし > て multibyte bidirectional port を support しない (できない) ので > memory の無駄です。 同一ソースに対してはScmCharPortかScmBytePortの排他利用を前提にし てます(FILEとfdの関係に類似)。双方向性については上述の通り。 > ところで encoding 指定は symbol 推奨。case 句に渡せるし、比較 predicate > が全部効くし、string-append で構築したくなるような事もないでしょう。もし > あっても symbol-append 作れば済みますし。 数字で始まるコードもあり得るようなので安全側に倒して文字列にしと いた方がいいと思います。canonicalizeすればいいという意見もあると 思いますが、canonicalizationの責任はこれより上の層に負わせたいで す。 $ iconv -l | sort | head 437 CP437 IBM437 CSPC8CODEPAGE437 850 CP850 IBM850 CSPC850MULTILINGUAL 852 CP852 IBM852 CSPCP852 855 CP855 IBM855 CSIBM855 857 CP857 IBM857 CSIBM857 860 CP860 IBM860 CSIBM860 861 CP-IS CP861 IBM861 CSIBM861 862 CP862 IBM862 CSPC862LATINHEBREW 863 CP863 IBM863 CSIBM863 865 CP865 IBM865 CSIBM865 また、ScmCharPortの層ではなるべくSigSchemeに依存させたくないと考 えてます。コードの再利用性(uim-scmにportしたり)やメンテナンス性、 設計の単純さの面から。 > > struct ScmPortCell_ { > > enum ScmPortDirection direction; > > ScmCharPort *impl; > > } port; > > ScmObj 圧縮したら direction は ScmCharPort の方に入れることになるのかな…? ポインタを収めるのと反対側のslotに格納できると思ってたんですが、 そうでないならScmCharPortに移しましょう。 > > /* output */ > > int (*vprintf)(ScmBytePort bport, const char *str, va_list args); /* tmp */ > > int (*put_str)(ScmBytePort bport, const char *str); > > size_t (*put_bytestr)(ScmBytePort bport, size_t len, const char *str); > > int (*flush)(ScmBytePort bport); > > }; > > flush 要らんす。VOLATILE_OUTPUT も要らんす。あれは C level で crash した > ときにもどこまで実行できたか確認するための機能ですが、よく考えたら > main.c で setbuf (stderr, NULL) した方が早いです。 Shiroさんのおっしゃる通りの理由で必要です。 > put_bytestr () は名前が非常に misleading。put_str() の方が文字コード変換 > をしそうに見える。普通に write () と puts() でいいと思うんですが… なるほど。そうですね。R5RSのwriteとwrite(2)を区別したかったんで すが、その2つはC由来の名前で統一しましょうか。 > > struct ScmFilePort_ { > > const ScmBytePortVTbl *vptr; > > > > FILE *file; > > }; > > ScmStdCharPortVTbl 持っとく必要があります。 どういう目的でしょう。ちょっとわからんす。 ------------------------------- ヤマケン yamak****@bp*****
