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.
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.
Practice what you learned
1. In Julia, what determines which method of a generic function is called?
2. If speak(a::Animal) and speak(d::Dog) both exist and Dog <: Animal, which method does speak(Dog()) call?
3. What happens when two methods are equally specific for a given call's argument types?
4. How can a plotting package add support for a type defined in a totally separate, unrelated package?
5. What macro shows exactly which method a specific call will resolve to?
Was this page helpful?
You May Also Like
Functions in Julia
Learn Julia's function syntax, multiple return values, keyword and optional arguments, and the mutating-function naming convention.
Anonymous Functions and Closures
Learn Julia's -> syntax for anonymous functions, do-block syntax, and how closures capture variables from their enclosing scope.
Loops in Julia
Master for and while loops, iteration over collections, break/continue, and performance-minded loop patterns in Julia.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics