good robots do what they're told

Implicit Parameters in Scala

Scala “implicits” allow you to omit calling methods or referencing variables directly but instead rely on the compiler to make the connections for you. For example, you could write a function to convert from and Int to a String and rather than call that function explicitly, you can ask the compiler to do it for you, implicitly.

In the next few posts, we’ll look at the different types of implicit bindings Scala offers and show some examples of when they can be useful.

Scala Learning Curve

If you’ve just started to learn Scala and are wondering what to expect, it’s typical to experience a quick ramp up in skill followed by a slower adoption of the more sophisticated features. In this post, I talk about what I think of as a typical learning curve.

Taken from my Pluralsight course, the chart shows experience (or time) along the x axis and some measure of “learning” on the y.

Scala Mixins: The Right Way

Scala traits are interesting because they can be used for inclusion polymorphism and to mixin behaviour. I’ve found tension here though, as the former uses inheritance and the later is more about code re-use. So when a Scala class extends a trait with behaviour, it seems to go against the generally accepted view that using inheritance as a mechanism for code re-use is a bad idea.

It can be tricky not break the inheritance vs. composition principle when using traits with behaviour. Is it clear to you when you might be?

Dealing with Exceptions as Monads

In some previous posts, I wrote about treating exceptions as a system wide concern. In this post, I extend that idea and talk about distinguishing between exceptional behaviour and just code that didn’t return what you wanted.

Pure functional languages often discourage the use of exceptions because when they are used to control execution flow, they introduce side-affects and violate purity of function. By using the type system to capture exceptional behaviour and dealing with exceptions monadically, it’s much easier to provide that system wide consistently I’ve been talking about.

Classes vs. Functions

You can use lambdas in Java 8 anywhere you would have previously used a single method interface so it may just look like syntactic sugar but it’s not. Let’s have a look at how they differ; it’s anonymous classes vs. lambdas or simply put, classes vs. functions.

Functional Interfaces in Java 8

Java 8 treats lambdas as an instance of an interface type. It formalises this into something it calls “functional interfaces”. A functional interface is just an interface with a single method. Java calls the method a “functional method” but the name “single abstract method” or SAM is often used. All the existing single method interfaces like Runnable and Callable in the JDK are now functional interfaces and lambdas can be used anywhere a single abstract method interface is used.

Let’s run through the basic syntax.

Method References in Java 8

Java 8 brings with it method references; shortcuts that you can use anywhere you would use a lambda. The Oracle docs describe four types of method reference but do such a poor job of describing them that I felt compelled to describe them myself.