Ytukyg

I have class Boy that inherits class Person, and includes module Bipedal. Both Person and Bipedal have versions of #two_legs.

module Bipedal

  def two_legs(name)

    puts "#{name} has exactly two limbs used for walking."

  end

end



class Person

  def two_legs(name)

    puts "#{name} has two human legs."

  end

end



class Boy < Person

  include Bipedal

  attr_accessor :name

  def initialize(name)

    @name = name

  end



  def two_legs

    super(@name)

  end

end

Since the Bipedal module is included in Boy, Bipedal#two_legs takes precedence over the Person#two_legs. When I call super on a Boy instance, the module Bipedal takes precedence over the parent class Person.

johnny = Boy.new('Johnny')

johnny.two_legs

# >> "Johnny has exactly two limbs used for walking."

I want to use one version in one place and the other in another. Bipedal has other stuff, so I can't comment out include Bipedal. Is there some standard way to let Boy#two_legs or super to use the parent class version instead of the module version as follows?

johnny.two_legs

# >> "Johnny has two human legs."

I came up with this:

Boy.superclass.instance_method(:two_legs).bind(self).call(@name)

which works in place of super(@name), but is more complicated than I was expecting.

Again, the question is, is there a standard way to force the parent class to take precedence over the module when calling super?

One could use the method Method#super_method twice. That being a garden-variety Ruby method, I believe it would qualify as a "standard way" to let Boy#two_legs invoke Person#two_legs rather than Bipedal#two_legs.

class Boy < Person

  include Bipedal

  attr_accessor :name

  def initialize(name)

    @name = name

  end

  def two_legs

    method(:two_legs).super_method.super_method.call(@name)

  end

end



willie = Boy.new('Willie')

willie.two_legs

Willie has two human legs.

Note the following.

willie.method(:two_legs).super_method.owner

  #=> Bipedal

willie.method(:two_legs).super_method.super_method.owner

  #=> Person

No, there is no standard way to force a call to super to walk the ancestors in a specific order. They are walked in a pre-defined order. Take a look at the documentation on calling methods:

When you send a message, Ruby looks up the method that matches the name of the message for the receiver. Methods are stored in classes and modules so method lookup walks these, not the objects themselves.

Here is the order of method lookup for the receiver's class or module R:

• The prepended modules of R in reverse order


• For a matching method in R
  


• The included modules of R in reverse order

If R is a class with a superclass, this is repeated with R's superclass until a method is found.

Once a match is found method lookup stops.

Since your class Boy includes the module Bipedal directly, and since included modules are searched before the superclass, and since searching stops once a match is found, the superclass Person is never checked.

The same is true when using refinements because the lookup always hits included modules before it checks the superclass.

If you move include Bipedal into the Person class then it will work the way you expect because Boy does not include a module directly, so it will eventually search the superclass where it will find the defined method.

There may be other creative ways you can accomplish this goal, like the Boy.superclass... example you gave, but you asked if it's possible to change the lookup behavior when calling super and the answer is no per the documentation.

I don't think you can change how super works and you can't "super super" to skip an ancestor but you can use a different ancestor. If you're just including Bipedal for some of its methods and want to skip a few of them then you could do something like this:

SemiBipedal = Bipedal.dup

SemiBipedal.remove_method(:two_legs)



class Boy < Person

  include SemiBipedal

  #...

end

Of course johnny.is_a? Bipedal won't be true anymore and Boy.ancestors will have SemiBipedal instead of Bipedal at index 1 but that might not matter.