Method dispatch: walking up from the receiver

Follow one call up the inheritance chain from the receiver's own class to the first body that implements the selected signature. Inheritance and polymorphism · Object-oriented programming.

A support app sends one notice through a variable typed Notice, but the object in memory is an UrgentEmail. The object you call a method on is the receiver, here the UrgentEmail. The call line is the same whatever the variable's type says. The question is where the program looks for the send body that runs.

By now the call has its signature, send(String); the overloading lesson showed how. This lesson asks only where the body is looked up.

Walk up from the receiver

class Notice {
    void send(String s) { System.out.println("base:" + s); }
}
class EmailNotice extends Notice {
    @Override void send(String s) { System.out.println("email:" + s); }
}
class UrgentEmail extends EmailNotice {}

Notice n = new UrgentEmail();
n.send("status");   // email:status
Notice m = new Notice();
m.send("status");   // base:status

Lookup starts at the object's own class, UrgentEmail, not at the declared type Notice. UrgentEmail has no send(String), so the search climbs to EmailNotice, which does, and that body runs. The same line on a plain Notice object stops at Notice. The variable's type never starts the search. For an instance method it only decides which signatures the compiler lets you call on that variable; the receiver's runtime class then decides which body is found for the signature the compiler selected. Two calls made through the same declared type can therefore reach different bodies.

Every body reached this way runs on the same object. Inside EmailNotice.send, this is still the UrgentEmail you called it on; climbing the chain changes which code runs, never who the receiver is.

super restarts one level up

class EmailNotice extends Notice {
    @Override void send(String s) {
        super.send(s);
        System.out.println("email:" + s);
    }
}
// UrgentEmail receiver: prints base:status, then email:status

super.send(s) is a fresh lookup that starts at the parent of the class whose code contains the call, here Notice. It does not start at the receiver's class and not at the receiver's parent. It still runs on the same receiver.

Python reads the order off the object

class Notice:
    def send(self, label): return "base:" + label
class EmailNotice(Notice):
    def send(self, label): return "email:" + label
class UrgentEmail(EmailNotice): pass

n = UrgentEmail()
print([c.__name__ for c in type(n).__mro__])
# ['UrgentEmail', 'EmailNotice', 'Notice', 'object']
print(n.send.__self__ is n)   # True
print(n.send("status"))       # email:status

Python reads the lookup order, called the method resolution order (MRO), off the object: type(n).__mro__ lists UrgentEmail, EmailNotice, Notice, object, and the first class defining send supplies the function. Reading n.send then binds that function to n, so self inside it is the same object as n, whichever class the function was found in. The search is first match wins: classes later in the list are never consulted once an earlier one defines the name. super().send(label) inside EmailNotice continues after EmailNotice in this list:

class EmailNotice(Notice):
    def send(self, label): return super().send(label) + " then email:" + label
# UrgentEmail().send("status") returns base:status then email:status

A short C++ boundary

In C++ a virtual call follows the object it points to, while a non-virtual call follows the pointer's own type. A call through a Base pointer to a virtual member reaches the final overrider for the object's dynamic type, which is its actual class; override asks the compiler to reject a signature mismatch. A call to a non-virtual member uses the member the pointer type names, even if the object is a Derived. A qualified call such as p->Base::speak() requests the base body directly.

Many compilers carry out the virtual choice with a hidden pointer (vptr) into a table of functions (vtable), but that is a common implementation model, not something the language requires.

In practice this is how you reason when you add a class in the middle of a hierarchy: callers below it now stop at the new class's send instead of reaching the one above, and calling super.send(...) is how the new body keeps the shared behaviour instead of copying it.

Recap

• Lookup starts at the receiver's own class and climbs to the first class that implements the selected signature.
• Every body reached runs on the same receiver; super.m() restarts the climb at the parent of the class containing the call.
• Python walks type(obj).__mro__ and binds the found function to the object; C++ gives the final overrider only for virtual calls, and vtables are a common model, not a guarantee.

Continue to the inheritance diamond, the last lesson of this module. It asks where the search goes when a class has more than one parent path, which a single chain like this one cannot show.

To practise telling a reference from the object it reaches, which is what the receiver is, trace a pointer chain in Linked List Fundamentals.