While Scala shares many similarities with Java, beyond a certain point the similarities end, and Scala provides powerful, concise solutions to programming problems that Java either does not address, or has much more verbose answers to, according to Daniel Spiewak in the concluding segment of his Scala article series.

In Scala for Java Refugees Part 6: Getting Over Java, Spiewak starts his tour of idiomatic Scala features with the problem of how to extend the functionality of Java classes at runtime:

The basic idea is that classes need not have fixed members, but that methods can be weaved into the class or instance depending on imports. This is similar to the concept of “open classes” supported by highly dynamic languages like Ruby...

As one would expect from a language not tied to such heavy legacy baggage, Scala has managed to solve the problem of class extensions in a very elegant (and type-safe) way... The ultimate answer to the problem of class extensions is…implicit type conversions...

Scala allows you to define methods which take a value of a certain type in as a parameter and return a value of a different type as the result. This in and of itself isn’t so unique until you add the real magic. By declaring this method to be implicit (which is a modifier keyword), you tell the compiler to automatically use this conversion method in situations where a value of type A is called for but a value of type B was passed...

The Scala compiler is also capable of intelligently finding the type you need given the context; more intelligently than just relying on assignment or method parameter type. This is where implicit type conversions become the enabling factor for extension methods.

Another notion Spiewak explains is operator overloading:

Scala ... is really much closer to how mathematicians envisioned operator overloading in Turing-complete languages. The distinction is simple: in Scala, method names can contain arbitrary symbols...

This may seem like a trivial point, but it turns out to be very powerful. One of the leading problems with operator overloading in languages like C++ and Ruby is that you cannot define new operators. You have a limited set of operators with hard-coded call semantics (less-so in Ruby). These operators may be overloaded within carefully defined boundaries, but that’s all. Neither Ruby nor C++ succeed in elevating operator overloading to the level of a generally useful technique...

In Scala, you can call your operators whatever you want because there is no special logic for dealing with them hard-coded into the compiler. Little things like * precedence over + and so on are hard-coded, but the important stuff remains flexible.

Next, Spiewak explains tuples and the ability to return multiple values from a method:

Tuples are fundamentally a way of pairing discrete pieces of data in some sort of meaningful way. Theoretically, they can be applied to many different scenarios such as returning multiple values from a method or examining key-value pairs from a map as a single, composite entity. Really the only thing preventing programmers from exploiting the power of such simple constructs is the lack of an equivalently simple syntax. At least, until now…

Tuples don’t have to be all the same type either... It turns out Scala allows you to put tuples to good use in a lot of ways. For example, returning multiple values from a method...

The final idiomatic Scala technique explained in Spiewak's article is higher-order functions and closures:

[In Java] you can’t just pass a method to another method and expect something to happen (other than a compiler error)... [The] anonymous inner class delegate instance pattern is really like a distant cousin to proper functionals...

Let’s assume for one blissful moment that we could rewrite Swing to take full advantage of Scala’s syntax. Let’s pretend that we changed the addActionListener() method so that it actually would accept a true functional as the parameter, rather than this ActionListener garbage...:

val button = new JButton("Push Me")
button.addActionListener((e:ActionEvent) => {
  println("You pushed me!")
})
add(button)

Instead of a bulky anonymous inner class wrapping around our block of statements, we pass an anonymous method... This method takes a single parameter of type ActionEvent and when called performs a simple println(). It is effectively the same as the Java example, except with one tenth the boiler-plate.

We can actually condense this example down even farther. We can take advantage of some of the flexibility in Scala’s syntax when dealing with function parameters and remove some of those nasty parentheses (after all, it’s Scala, not LISP):

val button = new JButton("Push Me")
button.addActionListener { e:ActionEvent =>
  println("You pushed me!")
}
add(button)

Concise and intuitive, with no nasty surprises like only being able to access final variables (Scala anonymous methods can access any variable/value within its enclosing scope). In fact, what we have here is currently the focus of a great deal of controversy within the Java language community. This, dear friends, is a closure.

What do you think of the Scala features discussed in the article?