This is Part Three of a series of articles on Java.next. In Part Three, I will explore how the Java.next languages (JRuby, Groovy, Clojure, and Scala) support dispatch.
For my purposes here, dispatch is a broad term covering various methods of dynamically choosing behavior: single dispatch, switch/case, pattern matching and multiple dispatch. These concepts are not generally grouped together, but they should be. They are used to solve similar problems, albeit in very different ways.
Let me start with single dispatch. In Java, methods can be selected based on the type of the object they are invoked on. All the Java.next languages support single dispatch, too:
In all of these languages, the actual implementation of
fly can vary depending on the run-time type of
vehicle. (Clojure also supports multiple dispatch, where the implementation can vary based on the type of
speed – more on that later.)
Another way to dynamically choose behavior is with a switch statement. Java has a simple switch statement, based on its historical kinship with C and C++. Switch statements have gotten a bad name, so much so that programmers are encouraged to replace them with polymorphism where possible.
This anti-switching bias is based on the limited kind of switching allowed in languages such as Java. In Java.next, there is a different story. The Java.next languages all have powerful switching capabilities, allowing you to switch on any criteria you like. As an example, consider a method that calculates a letter grade, taking input that is either a number or letter grade.
letter_grade in Ruby:
In Ruby, the switch/case variant is called
case. The Ruby
when clause can take arbitrary expressions. Above you see ranges and regular expressions side-by-side in the same
case expression. In general, the
when clause expects objects that implement a well-known threequals method,
===. Many Ruby objects have sensible
=== implementations: ranges match numbers in the range, regular expressions match strings containing the regular expression, classes match instances of the class, etc. But any object can implement
===, so you can implement arbitrarily complex dispatch with Ruby
letterGrade in Groovy:
In Groovy, the switch/case variant is called
switch. If you compare this code with JRuby, you will see minor syntactic differences:
switchkeeps faith with Java, so you have to
defaultwhere Ruby uses
..<whereas Ruby's uses
===. (This is not visible in the code sample, but you would need it to test case matches individually.)
The general ideas are the same. Both JRuby and Groovy provide far more powerful and general approaches than Java's
In clojure, as in many Lisps, you can switch on arbitrary functions using
cond. One possible approach to letter-grade would be:
In Clojure, regular expressions look like
in function above is not part of Clojure. I wrote the code the way I wanted it to read, and then wrote this function:
In Clojure, I probably wouldn't use a regular expression for the letter-matching step, but I wrote the example that way for symmetry with the others.
cond is just the tip of the iceberg. Clojure-contrib includes a set of macros for other variants of switch/case, and later in this article I will demonstrate Clojure's multiple dispatch.
Scala's pattern matching is a powerful generalization of the switch/case idiom in many programming languages. Scala provides out of the box support for pattern matching on
With pattern matching, implementing letterGrade is a snap:
In this implementation, numeric grades and letter grades are both matched first by type. Then, case expressions also allow a guard that limits possible matches to some condition. So, for example, the first case above matches only if
value is an
Int (type match) and between 90 and 100 (the guard).
Scala's guard expressions are cool, but the combination of type+guard does not exactly parallel the other implementations of
letterGrade, which rely on arbitrary predicates in case expressions. Scala can do this too: Scala extractors allow you to create arbitrary patterns. Here is one approach to
letterGrade using extractors:
Behind the scenes,
NumericA and friends are objects that implement an
unapply method to determine if and how a value should match the pattern.
Scala's pattern matching is much more general than the letter grade example shows. To see this, check out Daniel Spiewak's series introducing Scala for Java programmers. In Part 4, he gives an example of pattern-matching working in conjunction with case classes, which I will explore below.
Case classes offer several interesting properties when compared to regular classes:
These properties are so useful that Scala programmers use case classes for all kinds of things. But their true purpose is revealed in conjunction with patterns: Case classes work directly with pattern matching, without having to write an extractor as in the previous example.
printColor method pattern-matches
Blue to provide special behavior for basic colors. Because these are case classes we can capture the actual color value
v. All other colors fall through to a general
Color, which prints a more generic message.
Scala's pattern-matching is a signature feature of the language. How do the other Java.next languages compare? To implement
printColor in Clojure, I begin by defining a structure to capture a color:
Where the Scala example defined basic colors with case classes, in Clojure I can use functions:
Now for the fun part. I will define a multimethod named
color-string, which dispatches based on which basic colors are present in the color struct.
basic-colors-in is a dispatch function that reports which colors have nonzero values:
Now I can define multiple implementations of
color-string. The basic syntax is
So for the three pure colors, I can define color-string as
I can also provide a catch-all implementation by specifying a dispatch-value of
Multimethods are more powerful than polymorphic single dispatch in two important ways:
color-stringexample above, but see Runtime Polymorphism for an example.)
Like Scala's pattern matching, Clojure's
defmulti provides an extremely powerful and extensible dispatch mechanism.
Both the Scala and Clojure code above take special action for colors that are declared to be pure blue:
What about colors that are not declared as blue, but are, nevertheless, purely blue. These colors are accidentally blue:
The Scala example was written to dispatch based on type, so it treats accidentally blue colors different from "real"
Blues. The Clojure example, on the other hand, dispatches based on the actual color values, so all solid blues are treated the same, no matter how they are created.
Of course, nothing stops me from "fixing" the Scala example, e.g. by dispatching on something other than type:
Or, I could "break" the Clojure example by adding a type tag, and dispatching on that instead. Rich Hickey posted this example on the Clojure mailing list:
This version now works like the original Scala version, treating "accidental" blue differently from things marked with a
Note that multimethods are open. I can add new colors later without having to modify the existing code:
If you are a dynamic language programmer fearing the tyranny of the Scala compiler, pattern matching is a cause for rejoicing. With pattern matching, you can bypass static typing and get the flexibility of much more dynamic dispatch. Consider: Scala's pattern matching can be used to dispatch on arbitrary predicates. These predicates are not limited to type relationships known at compile time, so a Scala program that uses pattern matching as the cornerstone of its dispatch strategy can be as dynamic as an extremely dynamic Ruby program. Put another way: Scala's catch-all match default (
_) is the moral equivalent of Ruby's
Dispatch takes many forms. Single dispatch, switch statements, pattern matching, and multiple dispatch all meet similar needs: Selecting runtime behavior in response to varying runtime conditions.
Flexible dispatch is a key element of Java.next. All of the Java.next languages support dispatch strategies that are far more flexible than Java's single dispatch. These strategies are not perfectly interchangeable, but have a great degree of overlap. For example, Clojure's multimethods and Scala's pattern matching look quite different on the surface but can be used to solve similar problems.
Dispatch can be based on criteria more dynamic than the type system, even in Scala.