Robert Klemme wrote:
> Personally I find that the more interesting question.  Do you want to
> have the side effect of updating potentially many classes (and objects
> via their class and #extend)?  Maybe there is a better design choice?  I
> don't know your use case or what you need that behavior for.  Generally
> Matz pics _very_ reasonable choices so I tend to assume that the
> aforementioned side effect is usually not wanted.  Which does not mean
> that there is no use case for this.
> 

Thanks for you response! You are right. I have resolved this without 
using this trick and using plain .extends/include as you mentioned.

My use case is simple : i would like to develop a DSL language that 
provides sub-DSL language that you can switch at runtime.

For example, the top DSL is inside module ALang and i have two sub 
language extension in ALang_B and ALang_C like this:

module ALang
  def use(sublang)
    # remove all previously defined sublanguage method
    # ...
    # Load new sub language here
    instance_eval { require "alang_#{sublang}" }
    instance_eval "extend ALang_#{sublang}"
  end
  # here others A Language methods....
  # ...
end


module ALang_B
  def myABFunction()
    "myAB"
  end

  def self.extended(base)
    # perform init (declare dynamic methods...etc.)
  end
end

module ALang_C
  def myACFunction()
    "myAC"
  end

  def self.extended(base)
    # perform init (declare dynamic methods...etc.)
  end
end

________________
Using it like this:

require "alang"
include alang

use :B
myABFunction

use :C
# myABFunction should not be usable
myACFunction

________________


Do you any project that use sub DSL language loaded/unloaded like this?






-- 
Posted via http://www.ruby-forum.com/.