To clear some potential confusion, let me start with the following statements

• As far as I understand, inheritance is mostly about dynamic dispatch.
• I understand how virtual pointer table based inheritance works and I assume that this is what ‘classical’ inheritance refers to.
• I assume that ‘pure’ OO-style class-based inheritance refers either to either classical inheritance or hash-table based method lookups.
• I understand how prototypical inheritance works and how it is fundamentally different from class-based inheritance.
• I know how Ruby has constants, instance variables, class variables, singleton classes, etc. that act differently from methods in terms of inheritance and lookup. This question focuses on the method lookup.
• I know how methods are not a first-class citizens in Ruby as opposed to JavaScript’s functions.
• I know that JavaScript has values other than objects and that Ruby doesn’t.

Neither of the mentioned languages use what I refer to as class-based inheritance.

The thing that bothers me is that people seem to refer to similar things using contrasting terms. I know how JavaScript’s property lookup works and I consider it very closely related to how Ruby’s method lookup works. The question is targeted at the difference between what is labeled ‘prototypical inheritance’ with prototype-based lookup and ‘class-based OO inheritance’ with superclass-based lookup.

Basically, a JavaScript prototype seems to act the same as a Ruby class in terms of method lookup (with the exception that Ruby also traverses included modules), yet I often hear that Ruby is purely object-oriented and JavaScript does not have ‘real’ inheritance. The conceptual difference I see is that JavaScript’s first-class function objects use the same lookup as any other value, while Ruby’s method lookup obviously only works on methods.

To paraphrase, when executing the expression obj.method(), JavaScript doesn’t know it’s looking for a function in obj, it simply finds a value (maybe even using a getter) and tries to call it, while Ruby knows it searches for a method and uses the rules for method lookup. The difference is slightly more evident when ‘method()’ is not preceded by a dot, JavaScript then searches for a variable in enclosing lexical scopes, while Ruby searches the current scope for local variables and various superclasses for methods.

—

The first practical difference that comes to mind is that AFAIK there is no real OO-based analogy to the code below, and that Ruby seems to simulate this lack by using complicated rules by looking up different symbol types differently while still being as dynamic as possible.

class A { // Some base class
  print() {
    // this.props is used. If this was a function call it could easily be implemented in Ruby.
    console.log(this.prop); // the this-binding stays the same
  }
}

A.prototype.prop = 'A'; // Define <prop> in the base prototype.

class B extends A {}

instance = new B();
instance.print(); // 'A'

B.prototype.prop = 'B'; // Define <prop> in the inherited prototype
instance.print(); // 'B'

instance.prop = 'instance'; // Define <prop> in the object itself
instance.print(); // 'instance'

Nevertheless, the following code samples are very similar in how they work.

class A # Some base class
  def print
    puts 'A'
  end
end

class B < A; end # 'real' inheritance
class C < B; end # ditto

instance = C.new
instance.print # 'A'

class B
  def print # Shadowing of <print> in the top class
    puts 'B'
  end
end

instance.print # 'B'

class C
  def print # Shadowing in the middle class
    puts 'C'
  end
end

instance.print # 'C'

def instance.print # Shadowing using a singleton method
  puts 'instance'
end

instance.print # 'instance'

class A {
  print() {
    console.log('A');
  }
}

class B extends A {}
class C extends B {}

instance = new C()
instance.print() // 'A'

B.prototype.print = function print() { // Shadowing of <print> in the top prototype
  console.log('B');
}

instance.print() // 'B'

C.prototype.print = function print() { // Shadowing in the middle prototype
  console.log('C');
}

instance.print(); // 'C'

instance.print = function print() { // Shadowing using the object itself
  console.log('instance');
}

instance.print(); // 'instance'

Does the code above, i.e. being able to use dynamically-bound methods and to gradually narrow down their lookup path, represent the only similarity between the two inheritance models?