こんばんは、川合です。
OSASKにおけるプログラミングスタイルについての話です。書いたつ
もりになっていたのですが、まだ書いていなかったので、今日書きます
。
とりあえずテキストエディタからいきましょう。
もしテキストエディタを作れと言われたら、あなたはどうしますか？
・・・普通なら、テキストエディタにオープンコマンドとセーブコマン
ドを作り、オープン時にファイルを読み込んで内部形式に変換してバッ
ファに溜め、逆にセーブ時には内部形式を一般的なテキスト形式に変換
して出力するでしょう。これが普通です。
なぜ変換しなければいけないのかといえば、それは普通のテキストフ
ァイルのフォーマットが、挿入や削除に向いていないからです。まあte
ditcなどという、そのまま編集してしまう強引なエディタもありますが
（苦笑）、あれはどう見てもスマートな方法ではありません。
話題を転じて、ビットマップエディタについても考えてみましょう。
ビットマップデータもOSASKのグラフィックボックスの形式とはかけ離
れているので変換の必要がありますし、そのビットマップが圧縮されて
いれば、らっきょさんのライブラリなどを使って展開しなければいけま
せん。だからやっぱり、オープンとセーブが必要になります。
さらに話題を変えましょう。OSASKのバイナリエディタであるbeditc
は、このような変換が本質的に不要なので、ダイレクトにファイルに読
み書きできます。そしてセーブ機能がいりません。僕の考えるところで
は、これこそOSASKスタイルです。メモリマップトファイルの利点が生
きています。このスタイルではundoができないなどの問題はありますが
、それはいじる前のファイルをコピーして取っておくことで実現してほ
しいです（このコピーはアプリ側がテンポラリを作って自動でやっても
いいですし、ユーザがシェルを使って自前でやってもいいでしょう）。
さて一般的なテキストエディタがなぜOSASKスタイルのエディタにな
れないのかといえば、それはファイル形式が悪いからです。ビットマッ
プエディタについても同様です。それなら、エディタにとって都合の良
い内部形式そのもののフォーマットを、一般的なフォーマットとして提
唱してしまいましょう。そうすれば、あとは双方向コンバータを作れば
いいだけです。これでOSASKスタイルのエディタが作れます。
いやもちろん、OSASKスタイルのエディタじゃなければ駄目だというわ
けではありません。エディタとしてちゃんとしていればOSASKスタイルに
こだわることはないのです。僕だってOSASKスタイルじゃなくても推奨を
出すでしょう。しかしOSASKスタイルにはいいことがあるのです。それを
書きますから、納得できたらエディタを作るときはOSASKスタイルにする
ようにしようかな、と思ってください。
OSASKスタイルの良いところは、まず、セーブする前にアプリがバグ
で死んでしまったとしても、ただアプリを立ち上げ直してそのファイル
を読み込めばまた続きからはじめられるということです。もちろんOSAS
Kではアプリが死んでもメモリイメージはそっくり残りますが、内部形
式のぐちゃぐちゃを解読して残骸から復活させるのは結構大変なのです
。内部形式がどんなにぐちゃぐちゃでもそれなりに規格化してファイル
として独立していれば、メモリイメージを解読しなくて済むわけです。
もちろんアプリの死に方によっては、内部フォーマットファイルも異
常な状態になっているかもしれません。そうであればそれを修正するツ
ールを作るか、さもなくばあきらめて捨てるまでです。非OSASKスタイ
ルアプリが死んだ場合だって救えないものは救えないのです。OSASKス
タイルは、救える機会を大幅に増やして救うための手間を減らしている
だけです。絶対に大丈夫ということではありません。そもそもアプリに
バグが無ければいいんですが、まあ、そうも言っていられないので。も
ちろんアプリの突然死が恐いならまめにセーブしていればいいんですが
、それをしなくていいということです。
コンバータを通す面倒さについては、もちろん将来はシェルが必要に
応じてバックでやるようになるので、アプリは何も気にしないでいいで
す。もちろん現状では自前でやらなければいけないので面倒ですが。
またOSASKスタイルにするとなれば、この内部形式フォーマットも公
開することになります。まあ公開しなくてもいいんですが、公開してく
れる人も出てくるでしょう。一般に、アプリのワークエリアの構造を公
開するのはよっぽどの物好きだけですが、それがまあよくあることにな
るわけです。ということは、プログラマがお互いに自分の設計力を公開
する機会が増えるわけで、みんな賢くなれます。また使いやすいフォー
マットは人気が出るでしょう。内部形式ですから、サイズよりもプログ
ラムからの扱いやすさです。変に圧縮がかかっていればやりにくいだけ
でしょう。・・・のちのちには定番の内部形式が固まってきて、エディ
タを作るたびに内部形式を考えるなんてことはなくなるかもしれません
。
エディタの内容によって、ふさわしいフォーマットは様々でしょう。
テキストエディタだからこの形式がいい、とは限らないと思います。そ
れでいいです。だからテキストの形式だけでも大変な量になると思って
いますが、OSASKはそれに十分に対処できますし、シェルも対処できる
ようにしたいと思っています。そしてそのためのタグシステムです（ま
だ全然できていませんが）。
OSASKスタイルがうまくいってさらにアプリが拡張オープンに対応す
れば、エディット内容が他のアプリにリアルタイムで反映できるように
なります。たとえばhtmlブラウザであるページを見ていて、そのhtmlフ
ァイルをいじれば即座にそれがブラウザに反映されるわけです。・・・
なぜなら、テキストエディタがいじった部分を一時flushし、その内部
形式ファイルの変更を検知したリアルタイムコンバータがもとのhrmlフ
ァイルの該当部分を変更して一時flushし、さらにはそのブラウザに向
いた内部形式へ変換するためのリアルタイムコンバータがまた一時flus
hし、そしてそのシグナルを受け取ったブラウザは画面のその部分を描
画し直すわけです。
テキストエディタ
↓
[text用内部フォーマットファイル]
↓
リアルタイムコンバータ
↓
[htmlファイル(plain-text)]
↓
リアルタイムコンバータ
↓
[ブラウザ用の内部ファイルフォーマットファイル]
↓
htmlブラウザ
これはもちろんhtmlファイルだけではなく、ブラウザで表示されてい
るjpegファイルも同じ事です。
でもまあ、このような自動更新については、オープン・セーブモデル
でもまめにセーブするだけでできます（セーブした瞬間に更新される）
。間にコンバータが挟まらないだけです。だからこれについてはOSASK
スタイルだけのメリットとはいえないかもしれません。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/