ぼうメモ帳

2005-03-19

次期グラフシミュレータ(GraphSim3)に関する考察(6)

| 次期グラフシミュレータ(GraphSim3)に関する考察(6)を含むブックマーク

6回目です.だれだれです.疲れてきたので,この辺で一回止めておきます.

前回は,4番目と5番目について検討した.今回は,6番目と7番目について述べる.

  1. 不必要なコンストラクタ
  2. 入出力関数でのポート指定
  3. 入出力データの扱いづらさ
  4. 無駄なtry{}catch{}構文
  5. InterruptedExceptionの記述
  6. ステートマシンの分かりづらさ
  7. DefaultFunctionalModule

ステートマシンの分かりづらさ

手続き型言語なので仕方がないといえば仕方がない問題点.ステートマシンを記述するためには,「ステートを保持する変数」+「switch-case」文を使って,ガリガリステートを記述しなければならない.これは,一般的な手続き型言語と同じ.

で,なぜ問題かというと,PCAの機能回路はステートマシンにより記述される場合が多い.とくに,ストリームの並び替えや,ストリームパターンマッチングなどが多い.どれくらい多いかと言われると数字を出せないので困るが,本当に割合的に多い.

割合的に多ければ,それらにマッチした記述方法を提供しても良いのではないかというのが,いまの考え.だから,ある特定のステートマシンについては,特化した記法を導入することで,ステートマシンの分かりづらさを解消しようと言うこと.

DefaultFunctionalModule

いちいちこれを継承するのがだるい.あと,継承してしまうことで,Java唯一の継承ルートを潰してしまうのが勿体ない.

どういうものが理想か.一番の理想は,Runnableのような機構を導入することだ.Runnableは,継承を消費することなく,Thread処理を記述することができる.では,なぜ現状ではそれを実現できないのか.一重に名前空間の問題である.read/writeメソッドをどこから引っ張ってくるのかという問題を解消できない限り無理.

Runnableを実装するクラスが単独で記述されるとき,外部の名前空間を用いない場合,もしくはインスタンスを生成した後に,何らかの方法で外部から情報を与えるようにプログラムを書く.それが面倒なときは,インナークラス,もしくは無名クラスとすることで,コンテキストに存在する名前空間アクセスする.

read/writeメソッドは,その動作はコンテキスト依存する.そのため,コンテキスト情報を何らかの方法で与えなければならない.現状では,それをDefaultFunctionalModuleが行っていると言うわけ.

これをなくすことができれば,継承ルートを空けることができて,ハッピーになれそう.だから,問題点.ここまで来ると,私の求める美しさにのみ依存した問題っぽい雰囲気もないことはないけど...

次期グラフシミュレータ(GraphSim3)(予告)

| 次期グラフシミュレータ(GraphSim3)(予告)を含むブックマーク

まだまだ問題点は残ってるけど,言いたい事は言った.だから,次からは具体的な記述方法について考えてみることにする.すこし頭の中を整理して考えたいから,もう少し経ったらだけどね.

トラックバック - http://d.hatena.ne.jp/susumu/20050319
256867