どうもみずほです。
基本的には賛成ですが。
At Tue, 21 May 2002 00:58:08 +0900,
TADA Tadashi <sho@spc.gr.jp> wrote:
>
> ただただしです。
>
> On Mon, 20 May 2002 22:32:02 +1000 "NISHIO Mizuho" <gha@intrastore.cdc.com> wrote:
> >1) parser, reader, visitor, writerは何が生成するのか、
> >また生成する方法はどうするのか
>
> ちょうどこのあたりを悩んでいたところです。まだ決めかねてるので、お
> 知恵拝借。
>
> まず、reader/writerは同一クラス。で、tdiary.conf内の@io_classにそ
> のクラスを指定することで現在のHEADでも切り替え可能になっています。生
> 成はTDiaryクラスが行います。
クラスを指定する時にClassのオブジェクトを指定するのか、
それともクラスの名前を文字列で指定するのかどちらでしょう?
前者だと、TDiary#load_confを実行するまでに
reader等のファイルを読みこむ必要があるので、
ちょっと柔軟性に欠けると思います。
加えて、設定ファイルにエラーが出た場合に
エラーメッセージの変更が加えにくい気がします。
後者はちょっとややこしいですが、
evalかModule#const_getを使えば、実装は可能でしょう。
> ファイルを読み込んだreaderは、自分が読み込んだデータを、どのparser
> に渡せばいいか知っているというのはどうだろう。hnfだけに対応するreader
> は、hnfのparserを知っていて、そいつにデータの解釈を任せる。複数の記
> 述形式に対応したreaderは、読み込んだデータの記述形式に応じて、その
> 都度、適切なparserクラスを呼ぶ。
ちょっと話は変わりますけど、
仮にAとBとCとDとEというフォーマットがあって、AとBとCに
対応するparserとreader、Dだけに対応するparserとreader、
Eだけに対応するparserとreaderがあるとして、
これらからAとBとCとDとEに対応する
parserとreaderを作る際にはどういう風にするのが良いのでしょう?
readerがparserのことを知るという構成は
問題ないと思うのですが、
その情報を保持する方法、
readerからparserへのデータの受け渡しの方法、
データの読み込みの方法などを統一しておいた方が
単一のフォーマットに対応したreaderから
複数のフォーマットに対応したreaderを作るときに
楽になるのではないでしょうか?
# そこまで気にしないという考えでも
# 構わないとは思います。
> ただ問題は、parserとvisitorをちゃんと分けた場合、どの時点でvisitorを
> 登場させるべきなのかよくわからない。ここで現在、思考停止中です(笑)。
この辺りはparser、visitorの実装をしている人は
気にしないと思うのですが、どうなんでしょう?
> ># newを呼ぶことにすると、テストを作るのが面倒になるので、
> ># 止めて欲しいです。parserとかvisitorはtDiaryに
> ># 依存しないので、それ単体でテストし易い方が望ましいです。
>
> parserが依存しないのはわかるけど、visitorは何らかの形で多少は依存す
> るのでは? 少なくとも、visitor側にはtDiaryが要求するインタフェースを
> 作らないといけませんよね?
確かにインターフェースとしては依存します。
上記の文章の意味はtDiary側のファイルをrequireしなくても
テストは行うことが可能ということです。
***********************
NISHIO Mizuho
e-mail : gha@intrastore.cdc.com
|