無題

ここには発散した思索の断片を書きなぐっているので、恐らく他人には全く理解不能。
今日は対象を一つに絞って、理解可能な文章で書いてみる。

アプリケーションが扱う情報には様々な制約がある。
ここでいう制約とは、例えば、
「ユーザーのアカウント名は重複しない」というような類のものだ。

このような制約を、Squeakのような言語に於いてどう記述すべきなのか。

必ずしも正統派のMVCである必要はないが、ここでは一先ずMVCパターンを前提とする。
MVCに於いて、制約はモデルに属するという解釈が自然であるように思う。
従って、恐らくそれをモデルクラスに実装することになるだろう。
Squeakのような言語では、実装とは、普通、手続きの記述だ。

制約を手続きとして記述することには大きな問題がある。
大抵の場合、モデルが持つ制約はユーザーインターフェイスにも制約を与えるし、
与えるのがユーザーフレンドリーである場合が多い。
しかし、制約が手続きとして実装されていると、
ビューがそれを機械的に取得・具現化することが困難となるため、
モデルに定義した制約を、重複して、ビューやコントローラーにも実装することになるのだ。

この問題は、Validatorなどいうクラスで制約を括り出す程度の工夫では解決しない。
私が見るValidatorは、ビューに与えるもの、コントローラーで使うヘルパークラス、そんなのばかりだ。
私はこのValidatorを、モデルに、しかも出来れば宣言的に、与えたいのだ。

パワーが無くなったので、普段の調子に戻す。

Validatorのように制約をクラスとして括り出すことは重要だ。
そのような規約がないと、ビューが制約を解釈出来ないから。
ただ、やっぱり、それはビューに与えるのではなくて、
モデルに与える情報だと思う。

制約の集合はtraitsでは駄目なのか？
複数のtraitがある一つのセットメソッドを並列的にオーバーライド＆SUPERをコールって出きったけ？
きっと無理。

mix-inなら上手く行くのか？
上手く行きそうだが、全く宣言的でない。
であれば、宣言を手続きに変換するマクロを書くだけでは？
うむ。それは要するに、新しい言語だ。

制約をこのようにクラスとして実装することはクラス数の発散を招きそうだ。
クラス数の増大は本当に制御不能なレベルに達するのか？
制約をクラスとして実装することへの直感的な忌避の本当の理由は何か？
こういうのは現在考え中。
けど、「モデル ゲッター 副作用メソッド」のような呼び出しチェーンに対しても制約が保証されるようにすると、
Squeakの場合、そもそも制約はセッターに実装すればよいものではなく、やはりクラスとして実装しないといけない気もする。

他にも、モデルやそのエンティティーの名前をユーザーに分かりやすく示す必要がある、とかいう似た問題もある。
つまり制約だけではなくて、名前なんかもモデルに宣言的にマッピングしたいのだ。
本当に、こういう些細な問題の積み重ねのために無駄な作業ばかりを強いられることになるのだ。
レガシーなWebアプリなんて今の100分の1の労力で作れるはずなんだ。
なんというか、Perlのメソッドのアトリビュートみたいな感じのものを、
メソッドではなくて変数にも付与できないものだろうか。