D3になる前にRangeについて一度まとめましょう


投稿ツリー



前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2010/5/17 20:58 | 最終変更
tama  一人前   投稿数: 111
引用:

SHOOさんは書きました:
引用:

tamaさんは書きました:
Andreiとしては,templateがあるのでその辺問題ないと認識しているんじゃないですかね.継承を上手く利用した統一的なI/Oとか書いたことないのでどういう問題が発生するのかよく分かってませんが,静的なダックタイピングでなんとかなるんじゃないかなと思ってます(FileからNetworkに途中で変更,とかやったことないので…).
で,Andreiのアプローチで楽なのは,対象となるストリームが小さくなって,それを渡してあげればbuffered/unbufferedとかを簡単に切り替えれる所なのかなぁと.Rangeがラッパーになるので中身にまで手を出す必要がない.実際Andreiがどこまで考えてるのかは分からないのですが

統一的なI/Oが欲しくなる例として、入出力のモックを作る場合なんかがあります。私は、以前の研究で装置のマイコンからUSBでバイト列が送信されてくるものを取り扱っていましたが、装置が使えない状態になった場合など、実際の通信とは別の経路として、モックとの通信とで動的に切り替えてやりたい場合などがありました。そんな場合に入出力ストリームが便利なのかなと思います。
Rangeを使ったダックタイピングでこれをやるとしたら、Rangeで参照される中身を切り替える必要があると思います。ですが、それって要するにstream的な何かを自作しなければならないと言うことになりませんかね?
だとしたら、std.streamを消し去って一切使わないようにするよりは、最低限のインターフェースとして提供された方がいいのではないかなと思います。

#code(d){{{
(isActive ? device : mock).read();
}}}
装置の切り替えはこんな感じでは駄目なんですかね?現状のストリームだとそれぞれの状態を共有出来ないので,似たようなことになるとは思うのですが.
std.streamを消し去るのは自分もなんか勿体無い気がしているので,std.stdio.Fileのインターフェイスをベースに書き換えようかなぁとか考えてはいます.まぁでもそれが有用になるかどうかは書いてみないと分かりません.ただStreamがあると自分が書いているUnpackerも今みたいに配列ではなくStreamから取得すればよくなるので,色々楽になるのかなぁと思ったり思わなかったりです.
投票数:58 平均点:1.72
返信する
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2010/5/31 23:04
SHOO  管理人   投稿数: 658
Rangeのインターフェース((キーワードのinterfaceではなく))について、次のようなことがわかってきました。
基本的には、#1.2のInputRangeをはじめとする5つのRangeですが、その他、以下の機能をつけることが可能です。

- isInfinite((無限入力/無限出力/emptyが定数))
- hasSlicing((スライスを取得できる/opSlice(int,int)を定義している))
- hasSwappableElements((レンジの要素をswap可能/frontがref関数等))
- hasAssignableElements((先頭要素に代入が可能/frontがref関数))
- hasLength((.lengthプロパティを持っている))

以上機能をつけることで、一部関数ではより効率的なアルゴリズムを選択することが可能になります。
また、Andreiが他に提案しているものとして

- save((状態を保存することのできるプロパティ))
- swapFront, swapBack, swapAt((指定箇所の要素を交換する))
- sameFront((先頭要素が同一のものかチェックする))

があります。
以上の機能は、Rangeに対応しているものならば、可能な限りつけるべき属性となります。
投票数:34 平均点:5.00
返信する

このトピックに投稿する

題名
ゲスト名
投稿本文

  条件検索へ


メインメニュー

ログイン

ユーザー名:


パスワード:





パスワード紛失  |新規登録

Menu