■

昨日立てた目標が妄想に過ぎなかったことが分かりました。
現実的な妥協案を考えると、限りなく今あるものに近づく。
Webアプリのフレームワークの話でした。

本当はviewの層の独立性を高めたり、内部的な条件分岐を禁止したりたりしたかった。
それによって画面遷移図を自動生成するような機能を与えることが出来る。
何となく企画書用に画面だけを作ってみたら、実は実装作業の大半が終わっているというようなことをやりたかった。

構造体を表にしたり表を構造体にしたりする無意味な作業をしなくて済むよう、
ちゃんとしたオブジェクトデータベースを提供することもやりたかった。
それでいて、Viewとの関係までもが一瞬で可視化されるようにもしたかった。

CSSやJavaScriptを全く異種な外部リソースとしてではなく、
Squeakのコードと同じ感覚で扱えるような環境も提供したかった。
それを実現するためにView層の記述の仕方を根本的に変えたりもしたかった。
表と構造体のコンセプトのギャップと同様、HTMLのIDという概念はギャップなのだ。
seasideがフォームのNAMEを遮蔽しているのと同様、
DOMツリーの扱いもIDだのという概念を使うことなく透過的にオブジェクトにマッピングしなければならない。

squeakを選択するからには、正規表現を根本的に強化することもやりたかった。

ちょっと前にAdobeのFlexを使った。
Ajaxと比較したときの完成度の高さに関心した。
私がFlexを賞賛した比較対照はSqueakではなくAjaxです。
それはともかく、FlashはHTML的なWebアプリとは全然違う。
どちらが正解なのかは微妙だ。
今のHTMLなアプリなんて数年で滅亡する可能性もあるわけで、
新規の大きな課題としてそれに取り組むには躊躇したりもする。

ところでseasideで使っているcontinuationですが、
あれはcurrentなcontexの表面をコピーしているだけで、
contextが抱えているオブジェクトを深くコピーしているわけではない。
それだと復帰できるのはoopだけ、つまり状態まで復帰できるのはsmallintegerだけなわけですが、
そもそも一般にcontinuationというものはそういうものなのでしょうか？
closureと同様に似非なのでしょうか？