Thu, 7 May 2009

今日のこと

• iWork09買った。

今日のATDYM

• Composing Classes from Behavioral Building Blocks

今日のJust idea

• requires 指定したメソッドも alias できないと駄目な気がする*1
  • 「when two traits are composed, it may be that each requires a semantically different method that happens to have the same name. Unlike Eiffel’s renaming, aliases alleviate the problem only to a small extent.」って書いてあるし
  • あ、aliasできるのは正しいとしても、実装はalias元の名前を参照するから駄目か。結局、メソッド名に対するセマンティクスは揃ってないとうまくいかないと。*2

『Traitsの論文にあるexcludesの「This suppresses these methods 」の機能は実装されている*2が、「and turns them into requirements,」に相当する振る舞いはしない』

Moose::Roleのメソッドの競合(2) - 蛇足編

• requiredの定義はselfSends - providedだから、上記の考えは浅はかな気もして来た。
  • aliasしても、selfSendsは増えない*3
  • excludesしても、selfSendsは増えない
  • つまり、どちらもrequiredは増えない*4

*1:Taxの例のpriceメソッドのようにメソッド名がかぶりやすい狭い領域で威力を発揮する気がする。

*2:二つのTraitがpriceを「単価」と「合計金額」と言う違うセマンティクスでrequiresしてた場合、aliasでunit_priceとか用意しても、unit_price(たぶん誰も利用しない)を実装する必要性が増えるだけでメソッドがpriceを呼び出すのには変わらない。結果、priceに単価と合計金額の二つの機能のメソッドボディが必要となるがこれは不可能。

*3:selfSendsはB(メソッドボディ)の数以上にはならないので。aliasやexcludesが変化させるのは N(名前)→B の対応だけでBの数は増やせない。

*4:providedが減ることでrequiredが増えるかもしれないけど、母数は変わらない