Multiple Dispatch Explained

Analogy categoryAnalogies

What Multiple Dispatch Means

In single-dispatch object-oriented languages, a method call like shape.area() is resolved based on the runtime type of one privileged argument (shape), with the implementation living inside that type's class. Julia instead uses multiple dispatch: calling area(shape) resolves to a specific *method* of the generic *function* area based on the runtime types of all its arguments together, and there is no privileged 'owner' type — collide(a::Asteroid, b::Ship) and collide(a::Ship, b::Asteroid) are two independent methods Julia can select between based on both arguments at once.

🏏

Cricket analogy: An LBW decision doesn't depend on just the bowler or just the batter alone — the umpire weighs the ball's line, the point of impact, and whether a shot was offered, combining multiple factors at once, similar to how Julia's dispatch considers the types of all arguments together, not just one.

Defining Methods for a Generic Function

A *generic function* is just the name shared by a collection of *methods*; + itself has hundreds of methods in Base Julia, including +(x::Int, y::Int), +(x::Float64, y::Float64), and +(x::Complex, y::Complex), each compiled separately and selected automatically based on the argument types at the call site. You add a method the same way you'd define any function — Base.+(a::Point, b::Point) = Point(a.x + b.x, a.y + b.y) — and Julia's compiler picks this new method whenever + is called with two Point arguments, without touching any existing + code.

🏏

Cricket analogy: The single term 'dismissal' in cricket covers many distinct mechanisms — bowled, caught, LBW, run-out — each with its own specific rule set applied depending on exactly how it happened, similar to how the generic function + has many distinct methods selected by argument type.

You can inspect exactly which methods exist for a generic function with methods(+), and see which specific method Julia will choose for given argument types with the @which macro, e.g., @which 1 + 2.0 reports the +(x::Number, y::Number)-family method actually selected.

Abstract Types and the Dispatch Hierarchy

Julia's type system separates abstract types, which exist purely to organize a hierarchy (abstract type Animal end), from concrete types that can actually be instantiated (struct Dog <: Animal end). Dispatch picks the *most specific* applicable method: if you define both speak(a::Animal) = println("...") and speak(d::Dog) = println("Woof"), calling speak(Dog()) uses the Dog method because it's more specific in the type hierarchy, while any other Animal subtype without its own method falls back to the general Animal method.

🏏

Cricket analogy: 'Bowler' is a general role, while 'left-arm orthodox spinner' is a much more specific one, and a captain's specific field-placement instructions for that exact bowling style override the generic bowler instructions, mirroring how Julia prefers the more specific Dog method over the general Animal one.

Ambiguities and the Most-Specific-Method Rule

Because dispatch depends on *all* argument types together, it's possible to define two methods where neither is strictly more specific than the other for a given call — e.g., combine(a::Number, b::Any) and combine(a::Any, b::Number) are both applicable and equally specific for combine(1, 2), producing a MethodError for ambiguous dispatch rather than an arbitrary silent choice. The fix is to add a third, more specific method that explicitly covers the ambiguous overlap, such as combine(a::Number, b::Number), which Julia will then prefer over either of the two original methods.

🏏

Cricket analogy: If two fielders both call for the same catch simultaneously with equal confidence and neither yields, the result is a collision or a dropped catch rather than a clean take — the ambiguity has to be resolved beforehand by a clear calling hierarchy, just as Julia raises a MethodError rather than guessing between equally specific methods.

Method ambiguities are only reported as errors at the moment an ambiguous call is actually made, not when the conflicting methods are defined — a package can silently contain a latent ambiguity for years until a specific combination of argument types finally triggers it. Running Test.detect_ambiguities(YourModule) during CI catches these before users do.

Why Multiple Dispatch Enables Extensibility

Because methods are defined externally to the types they operate on, any package can add a new method to an existing generic function without modifying either the function's original package or the type's defining package — a plotting library can add plot(m::MyModel) for a type defined in a completely unrelated statistics package, and both packages compose automatically. This solves what's known in language design as the 'expression problem': adding new types and adding new operations are both easy in Julia, whereas single-dispatch OOP makes adding new operations to existing types awkward, and functional pattern matching makes adding new types to existing operations awkward.

🏏

Cricket analogy: A third-party analytics company can build entirely new stats (like 'pressure index') on top of official ICC match data without needing the ICC to change its scoring system or the analytics firm to control the original data feed, mirroring how a Julia package can add plot(m::MyModel) without touching either the plotting or modeling package.

julia

abstract type Animal end
struct Dog <: Animal end
struct Cat <: Animal end

speak(a::Animal) = println("...")     # generic fallback method
speak(d::Dog)    = println("Woof")    # more specific method wins for Dog

speak(Dog())   # "Woof"  (most specific method)
speak(Cat())   # "..."   (falls back to the Animal method)

# Extending a generic function for a custom type, from anywhere
struct Point
    x::Float64
    y::Float64
end
Base.:+(a::Point, b::Point) = Point(a.x + b.x, a.y + b.y)

methods(+)              # lists every method of the + generic function
@which 1 + 2.0          # shows exactly which + method this call resolves to

Multiple dispatch selects a method based on the runtime types of ALL arguments, not just one 'owner' object.
A generic function (e.g. +) is a name shared by many methods, each compiled and selected per concrete argument types.
Dispatch prefers the most specific applicable method in the abstract-type hierarchy (Dog over Animal).
Ambiguous dispatch, where two methods are equally specific for a call, raises a MethodError rather than guessing.
Ambiguities are fixed by adding a more specific method that covers the overlapping case explicitly.
Any package can add methods to any generic function for any type without modifying either's source — this is Julia's answer to the expression problem.
methods(f) lists all methods of f; @which shows exactly which method a specific call resolves to.