原です。

 >けいじゅ@日本ラショナルソフトウェアです.
 >
 >>|scope-in-stateの方は, 状態自身をスレッドに持たせその状態に応じて, クラ
 >>|スの定義を変えようってものになっています. ただ, 自由に変えるのは不可能
 >>|なんで, 見た感じとしては状態に応じてincludeされているモジュールを入れ
 >>|替えてそのモジュールで定義されているメソッドが有効になるようになってい
 >>|ます.
 >>
 >>これそのものは面白い考えですよね。整理して取り込みましょうよ。
 >
 >では, 今の考え方を紹介します. 

すばらしー、大傑作ではないでしょうか。これで、多くの問題がうやむやに
、、、いや、解決できますね。(^^

私も似たようなことを考えていたんですが、スレッドを考えると難しくて
やめてしまいました。

思いつくままに意見を:

 >モジュールSは状態を表しているつもりです.  ここで, S::FooはFooに追加さ
 >れるモジュール, S::BarはBarに追加されるモジュールです. 一度に複数のク
 >ラスの振る舞いを変えることができないと意味がないので, こんな感じになり
 >ました. 上記の場合 S::Mod1::Mod2::Mod3は Sを取ったもの, つまり
 >Mod1::Mod2::Mod3に追加されます.

複数のモジュールを同時に考えると便利ではあるけれど、そのために使
い方が、ちょっと手間が必要になっていないかなあ。ネストができるの
だから素朴に

class Foo; def foo; 0; end; end
class Bar; def bar; 0; end; end

module Foo1; def foo; 1; end; end
module Bar1; def bar; 1; end; end

foo, bar = Foo.new, Bar.new
ScopeInState.new(Foo, Foo1).in_scope do
   p [foo.foo, bar.bar] #=> [1, 0]
   ScopeInState.new(Bar, Bar1).in_scope do
     p [foo.foo, bar.bar] #=> [1, 1]
   end
end

みたいなので十分では?


あるいは、

Foo.in_state(Foo1) do
   Bar.in_state(Bar1) do
     p [foo.foo, bar.bar] #=> [1, 1]
   end
end

みたいなインターフェースだと見た目がいいかも。しかし、Foo.in_state 
が Foo の状態を替えるところが気持ち悪いかな。


 >1. 上記のような単純な場合はわかりやすいが, ベースのクラスが継承したり
 >   includeしていたりすると, どう動作するのか想像しがたい.

 >1.は, 状態スコープで定義されたものが優先されるはずです. 概念的にはベー
 >スクラスで定義されたメソッドを状態に応じて変えるので, ベースクラスのメ
 >ソッドと同レベルと判断したからです.

include されたモジュールのメソッドに関してもすげ替えができるようになっ
たらうれしいなあ。つまり、

module M0
   def foo; 0; end
end

module M1
   def foo; 1; end
end

class Foo
   include M0
end

module S
   module Foo
     include M1
   end
end

ScopeS = ScopeInState.new(S)
foo = Foo.new
p foo.foo #=> 0
ScopeS.scope_in do
   p foo.foo #=> 1
end
p foo.foo #=> 0

みたいに。


 >2. 状態スコープのネスティングができるようになっているが, そのため実装
 >   が複雑&&実行コストがかかっている

このモジュールは整数の割り算とか、頻繁に実行される基礎的なメソッ
ドにも使われる可能性が大なわけですよね。だから、実行コストの問題
は、実験してみないとわからないけど、非常に大きいかもしれませんね。

scope の入り口と出口でメソッド書き換えるのが、多分そのメソッドの
実行コストは一番小さいけど、そうするとマルチスレッドと両立できな
いですよね。ただ、大きなコストの差があるなら、そういうバージョン
も欲しいです。