From: Phrogz <gavin@...>
Date: 2007-03-23T04:50:08+09:00
Subject: Re: What is the problem with this module function.

On Mar 22, 11:31 am, SunRaySon <sunray...@gmail.com> wrote:
> Now I am just curious to know if there is any way I can call the
> module function foo from instance a1.

module M
  def foo; "M#foo #{self.object_id}"; end
end

class A
  include M
  def foo; "A#foo #{self.object_id}"; end
  def mfoo
    M.instance_method( :foo ).bind( self ).call
  end
  def superfoo
    true_ancestors = self.class.ancestors - [self.class]
    true_ancestors.each{ |anc|
      if m = anc.instance_method( :foo )
        return m.bind( self ).call
      end
    }
    nil
  end
end

a = A.new
p a.foo, a.mfoo, a.superfoo

> Also is there any reason why mixin modules are looked upon first
> before looking at superclasses, again I am mistaken here I was opinion
> that it would be supreclass and then mixin modules.

Your expectations surprise me. Did you expect that if you had:

  class A; end
  class B < A; end
  class C < B; end
  class D < C
    include M
  end
  class E < D; end
  e = E.new
  e.foo

that Ruby would look for Foo in E, D, C, B, A and *then* look in M?
Or did you expect E, D, C, M, B, A?

Ruby looks in E, then D, then M, then C, then B, then A. The reason
(or at least a reason that makes sense to me) is:

a) Look in yourself before you look any higher.
b) Modules explicitly included in yourself are more important than
your superclass.

I think these make sense. Do they make sense when you think about them
like that?