From: "David A. Black" <dblack@...>
Date: 2005-09-12T10:07:24+09:00
Subject: Re: [Q] how to well-qualify the 2-inherited methods at their collision point

Hi --

On Mon, 12 Sep 2005, SHIGETOMI, Takuhiko wrote:

> dear guys,
>
> i'd like to ask you how to qualify the inherited methods from base class
> and mixed-in module at the collision point of inheritance, as below...

I don't think you can.  However... does this help?

   class SubClass < BaseClass
     MyBaseModule = BaseModule.dup
     module MyBaseModule
       def greeting
         super
       end
     end
     include MyBaseModule
   end

or, more concisely:

   class SubClass < BaseClass
     include BaseModule.dup.module_eval {
       def greeting
         super
       end
       self
     }
   end

That may just displace the problem.  But it may give you some ideas.

>  def greeting        # <== collision point of 2-inherited 'greeting'

Hmmmm....  I don't really think it's a collision.  It's more like
they're layered.  Understandably, Ruby thinks that if you redefine a
method later in the method lookup path, you *want* it redefined :-)

> i'd be happy if i could qualify their belongingness alike C++'s
>
>    BaseModule::greeting
>    BaseClass::greeting

I think it's better to have it all controlled by the object.  Whatever
the object thinks "greeting" means, that's what it means.  "super"
(jumping one level from a method definition body) makes sense because
when you redefine a method, you are adding one and only one layer.  So
you're "allowed" to know that there is one previous layer; that just
means you know that you're redefining a method, not defining a new
one.  But beyond that it I think absolute paths like that would lead
to tightly coupled class and module designs.


David

> any hacky way would be welcome.

Glad to hear it, considering what I wrote in the code above :-)


David

-- 
David A. Black
dblack@wobblini.net