From: Kurt Stephens <ks@...>
Date: 2008-06-24T13:40:33+09:00
Subject: [ruby-core:17391] Re: Any reason for having no module exclusion functionality in Ruby

ara.t.howard wrote:

> class DSL
>   instance_methods.each{|m| undef_method m unless m[/__/]}
> 
>   def initialize object, &block
>     @object = object
>      instance_eval &block if block
>   end
> 
>   def this_is_a_dsl_method
>     @object.something_on_object
>   end
> end
> 
> this is much preferred to extend/unextend imho because you can have
> methods in your dsl which are named the same as methods over the object
> - esp methods like 'send', 'name', etc, which can easily be desired
> 'keywords' in a dsl.
>  

We cannot replace instances with "DSL" proxies because we are creating complex
object graphs that require honoring side-effects in new/initialize.  The DSL,
in our case, defines a set of methods that can be added or removed at
run-time.  Basically we are doing something similar to the contextr gem
(context-oriented programming) to temporarily redefine methods that bind two
large systems together, during testing.

Insertion of a proxy is difficult because we would have to find all
creation sites of the objects we are trying to temporarily redirect or
redefine new.  Proxies can not be easily "disabled" or "reenabled".  Proxies
tend to break the "isa" relationship in subtle ways.  We want to be able to
use the same object graph during different tests by enabling or disabling the
contexts that removed or reintroduce the coupling.

> that said i'd wholeheartedly embrace Ojbect#unextend
> 

Object#unextend and Object#uninclude would make context-oriented techniques
much more efficient.

> kind regards.
> 
> 
> a @ http://codeforpeople.com/

Kurt