From: ts <decoux@...>
Date: 2001-08-12T20:37:35+09:00
Subject: [ruby-talk:19591] Re: order and freedom in Ruby (was: Re:  Re: the way class variables work)

>>>>> "M" == Mathieu Bouchard <matju@sympatico.ca> writes:

M> mixins work with 'pointers' as well. I think the problem Guy is showing is
M> that Classes cache method lookup, but Modules don't implement Observable,
M> so Classes can't subscribe to them, so Classes can't know when Modules
M> change, and thus can't invalidate their caches.

 Well, yes and no.

 mixin work with 'pointers' this mean that when you write

   module B; end;
   module A
      include B
   end

 Internally this is represented like this

          B
          ^
          |
  A ==> (IC)

 i.e. ruby has created an included class and this class (through its
pointer) make direct reference to B

 This is a little different with this case

   class C
      include A
   end

 this time this will be represented like this

          A       B
          ^       ^
          |       |
  C ==> (IC) ==> (IC)

 this mean that ruby has completely linearized its search path, and the
algorithm to find a method is really simple because ruby work on a linear
path.

 This is true that when a module change (via mixin), a class don't know
 this modification and can't try to re-build its path.

 If you look at my example, you'll see that the method that I've defined in
 B has a new name, and in this case the cache is not used (i.e. this is not
 a problem of cache).



Guy Decoux

p.s. : when you have seen this, the first stupid idea that came is that
ruby has made something like this

  C < A < B

 i.e. ruby has ordered these classes from the most specific to the least
 specific and if you follow this idea you came with a *more stupid* idea,
 and this idea give you the dispatch on the type :-)))