From: SunRaySon <sunrayson@...>
Date: 2007-03-24T12:53:02+09:00
Subject: Re: What is the problem with this module function.

Oops! Now I understand how dumb I was, in expecting the superclass
methods being looked upon first.

Kiran.


On 3/23/07, Phrogz <gavin@refinery.com> wrote:
> 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?
>
>
>