今回、紹介した「未来」の機能は以下の通り。argumentsNamespaces今まで話してきたことじゃん、と思うでしょうが、その通り。違いはこれらの機能が単なるアイディアではなく、どのように実装すべきかほぼ見えている実装した機能を突っ込む場所(trunk)が明確になっている点です。(en)ということで、モジュールとほぼ同じようなものです。実際、今回導入するTraitsは言語要素の実体としてはモジュールを利用します。includeの方が便利なこともあるので、includeもなくなりません。includeの問題は名前の重複を検出できないことモジュールのinclude関係が後から変化した場合の一貫性のない挙動メソッドを後から修飾する(wrapする)方法が提供されないことです。includeされたモジュールが継承ライン(ancestors)に含まれるようになります。この時、状況によっては予測困難なことが発生します。区別する手段がないところです(名称重複問題)。(ので、メソッド名の重複時にどれが優先になるのか直感的でない)ことです。重複していますが、これが意図的な重複なのか偶然かは言語にはわかりません。継承ラインの順にしたがってメソッドを呼び出すだけです。ひとめでそれが分かるのは、だいぶ「訓練されたRubyist」です。二重にincludeしない」という挙動になっています*1。いうことが起こりえます。存在するクラスの継承ラインには新たにincludeされるようになったモジュールは含まれません。includeのタイミングによって継承ラインへの反映のされ方が異なるわけです。これらを(ある程度)解決する手段がmixメソッドです。重複したメソッドの名称を変更する定数を取り込むかどうかを指定できる。デフォルトは取り込まないという振舞いになります。継承ラインが変化した時の「おかしさ」がない。問題は解決していないが、気分は良い(苦笑)ということが実現できます。conflict!endaddressメソッドが重なっているからmixできません。無事mixさせるためには名称衝突を明示的に回避します。:jp_addressendこれで、addressという名前による重複はなくなりました。ユーザーをそちらに誘導するためには、より短い名前の方が望ましいと思ったからです。パッチは完成しているそうです。これらについては結論を出す必要があります。mixされるモジュールが別のモジュールをincludeしていた場合にはどうなるか。mixとincludeは混ぜるべきではない。実際にはモジュール内部で名前を書き換える前のメソッドを読んでいる可能性がある。MayerのOOSCに記述されていたアイディア)を導入することを考えるインスタンス変数の名称重複を解決する手段がない。違うナニかを考えるのかが難しくて現状では放置されています。mixが導入されたらより必要になるでしょうね。