From: Trans <transfire@...>
Date: 2006-12-29T23:13:52+09:00
Subject: Re: override.rb


ara.t.howard@noaa.gov wrote:

>
> so, while it is a true statement that __each__ call to 'override' introduces a
> new mixin module, it is not true that __every__ call to 'restore' leaves an
> extraneous module mixed in, though it's possible that a given call to
> 'restore' may indeed have that effect.
>
> make sense?

sure, it makes sense, but you do have that possibility. and i agree
it's not such a big deal. just pointing it out. i also point out that
the idea of override.rb is but a step from the idea of cuts. in fact
implementation of overide using cuts is little more than:

  def override &block
    Cut.new(self,&block)
  end

and my hacked-up pure ruby implementation of cuts is very similar in
design that of override.rb.

moving slightly off-topic. have you ever thought about the possibility
of every method being as if it were it's own module?

  class X

    module A
      def a; "a"; end
    end
    include A

    module B
      def b; "b"; end
    end
    include B

  end

the ablity to dynamically manipulate behavior goes way up.

  class X
    module A2
      def a; '{'+super+'}'; end
    end
    include A2
  end

of course so does the overhead. (and the dynamic inclusion problem
still lurks in the background).

t.