言語ゲーム

とあるエンジニアが嘘ばかり書く日記

Twitter: @propella

一般的で形式的な GUI フレームワークの研究 2

現実逃避的に http://d.hatena.ne.jp/propella/20070129/p1 の続き。GUI フレームワークを形式的に設計するのに Functional Reactive Programming が有効である事が分かったわけですが、さらに調査を進める前に今の自分の考えをまとめます。

目的

あるモデルを画面上で操作するためには大まかに二つの手法があります。

  • 更新伝播(MVC)
    • モデルが更新された時点でそれを参照しているビューをすぐに更新する。
    • 利点: ビューが確実にモデルに反映される。
    • 欠点: モデルの更新頻度が高いと無駄。例えば一秒間にモデルが 1000回更新されてもどうせ見れない。
    • 欠点: モデルからビューへの暗黙の参照が必要。
  • ポーリング(Morphic, 普通の Web アプリ)
    • モデルは勝手に更新されていて、ビューは特定の時間間隔でモデルにアクセスして更新する。
    • 利点: モデルからビューへの参照が無いので単純。
    • 欠点: いつ更新されるか分からないので、モデルが更新されてないのにビューの更新をしなくてはならない。

普通はこれらの方式を組み合わせた実装を選択しますが、一般的で形式的なGUI フレームワーク(長いので不本意ですが以後 GFGF - Formal Generic GUI Framework と書きます)では、どちらの方式を選択したとしても全く同じ結果になる事を保証しなくてはなりません。つまり、どっちか良いか僕もよく分からないので後で考えたいのですが、同じ事が出来るようにする必要があるという事です。だから GFGF を二つに分けます。

  • 論理 GFGF : モデルとビューの関係を扱います。
  • 物理 GFGF : ビューの表示の仕方を扱います。

このうち、論理 GFGF については、 Functional Reactive Programming の世界ですでに答えが出ているのではないかと予想しています。まだ勉強中だけど、10年も昔に FAL のような物が完成しているという事は新型のやつは相当すごいと期待しています。という事は、オブジェクトの汚い海に住む我々の仕事は物理 GFGF にあるでしょう。

論理 GFGF

論理 GFGF は次のものを扱います。

  • モデルを更新する方法
  • モデルからビューを求める方法

例えば FAL の真似をして、モデルをストリームとして扱う事を考えます。デスクトップ時計を作るとすれば、今の時刻を表す値はただの変数ではなくて、数列にカーソルが付いたものを思い浮かべます。狂った時刻を直す事を考えます。ユーザは今や過去の時刻を修正する事は出来なくて、出来るのは未来の時刻にイベントを渡す事だけです。時刻を表示するビューは誰かが勝手に今の時刻を書き換える事が無いので、安心して表示する事が出来ます。大まかに言うと、こういうのを「参照透明性がある」と言います。

ユーザが触るのはこのレイヤです。つまり、ユーザは副作用について全く心配する必要がありません。ユーザの書いた副作用のあるプログラムも勝手に副作用の無い形に書き換えられます。

物理 GFGF

物理 GFGF では、更新頻度の問題とか、キャッシュについて扱います。論理 GFGF をこの層から切り離す事によって、ヒューリスティックに決めがちなこういった問題を、きちんと定量的に評価出来るようにします。このレイヤは副作用を生みますが、論理 GFGF の層に影響を及ばしません。

と、ここまで考えて疲れたので休憩します。今日の話のポイントは、GUI フレームワークを二層に分けるべきだという主張でした。おわり。