D I/O model考察

はるえす＠イカのフレンズ @Rayerd

同じことだけどメモ。auto range=isUtf8Source(binary_src)?Lined!string(binary_src):Lined!wstring(binary_src);

はるえす＠イカのフレンズ @Rayerd

@9rnsr いや、エンコードを見てからの分岐みたいなのはライブラリでどうこうするものではないみたいだなーと思ったくらいです(>.<)

SHOO @mono_shoo

これよさげだなぁ。私が考えてるのと結構マッチしてる。私のやつの場合、これらをinterface/class化できるのが入る程度かな。考え方的に。 RT @9rnsr: ローカルで作業中のI/Oモジュール http://bit.ly/hezLGb …

hara kenji @9rnsr

@Rayerd 自分としてはstd.encoding.EncodingSchemeのリストを与えてAutoEncodedを構築するとか妄想していました。Gaucheにエンコーディング認識ポートとかあるので似たものは作れるかなと。

hara kenji @9rnsr

@mono_shoo Dなのでテンプレートありきで作ってましたが、Source/Pool/SinkのI/Fがまとまってくるとinferfaceでもいいかなと思えてます。

はるえす＠イカのフレンズ @Rayerd

速度、型安全、ポリシーベース、静的多態、動的多態、あとDのIOが満たしていなければならないのはなんだ

SHOO @mono_shoo

私の考えてるI/Oモジュールの究極的な要求はただ2点に絞られる。一つ目は入出力デバイスを定義しやすいこと。もう一つは、テキスト/バイナリ処理、エンコード、バッファ、その他もろもろはライブラリが用意しているヘルパを使って、いろんなデバイスを統一的に扱えること。 #d_lang

はるえす＠イカのフレンズ @Rayerd

レンジベース、アルゴリズム、

hara kenji @9rnsr

I/O要求に対する自分の考え：読み出しのバッファリングは基本コンセプトに組み込む(自分はPoolと呼んでいる)。テキスト処理はバイナリストリームにかぶせるFilterが担当する(改行とか行分割とか)。

hara kenji @9rnsr

エンコーディングはある程度のバイナリチャンクが参照できるなら自動判別も可能と考える。予め判っているなら型付けするFilterを適用すればいい。ネットワークはコネクション確立後のみを想定している。

hara kenji @9rnsr

レンジベースアルゴリズムに対してはRange化するFilterを書ける、ただしBlockingI/O前提だと思っている(NonBlockingはpollingでBlock化する？)

SHOO @mono_shoo

ヘルパはストリーム専用でも構わないし、Rangeで対応するのでも構わない。バッファリングとかぶっちゃけどうでもいい。A先生、どうでもいいから基本コンセプトさっさと作ってくれってのが本音。

hara kenji @9rnsr

レンジベースアルゴリズムに対してはRange化するFilterを書ける、ただしBlockingI/O前提だと思っている(NonBlockingはpollingでBlock化する？)

SHOO @mono_shoo

@9rnsr ヘルパは限定的なものでもいいと思うんです。プリミティブな部分で、環境に依存せず低レイヤーに触ることが出来るのであれば。

hara kenji @9rnsr

@mono_shoo はい。そこは私も思います。最終的にRangeで提供できれば中間フィルタまでRangeにする必要はないかと。