Implicit Parameters, Conversions, and Their Resolution

Scala has an incredibly powerful feature called implicits. When you ask for a value implicitly, such as a method parameter, or the implicit keyword you are telling the Scala compiler to look for a value that has the same type in scope. This is unlike the explicit value, where you need a type to specify when it's called/used. A practical use case for implicits is providing an API key for a REST web service. The API key is typically only provided once, so an implicit is a good use case in this instance, since you only need to define and import it once.

case class ApiKey(id: String)

Since implicits are found by their type you need to create a new type, in this case ApiKey. Now let's define a method that makes a HTTP call.

import scala.concurrent.Future

def getUser(userId: Long)(implicit apiKey: ApiKey): Future[Option[User]] = ???

In order to call this function you must make sure that an implicit ApiKey is visible in the scope. Let's first make an instance of ApiKey and place it in an object.

object Config {
       implicit val apiKey = ApiKey(System.getenv("apiKey"))
}

Whenever you call getUser, ApiKey needs to be visible, and the code should look something like this:

import Config._ // This imports everything in Config, including implicits

object Main extends App {
val userId = args(0).toLong
       getUser(userId)
}

It's also possible to supply an implicit argument explicitly.

object Main extends App {
  val userId = args(0).toLong
  val apiKey = ApiKey(args(1))
  getUser(userId)(apiKey)
}

Implicits can be used to make automatic conversions between types; however, such usage is considered advanced and should be done sparingly, because it's easy to abuse code that uses these features. A prominent use of implicit conversions is in DSLs. For example, if you have a trivial DSL that attempts to represent SQL queries, you might have something like this:

Users.filter(_.firstName is "Bob")

In this case, _.firstName may be a different type from a String (in this example, let's say it has type Column[String]). And it can only work on types of Column[String]:

val columnStringImplementation = new Column[String] {
       def is(other: Column[String]): EqualsComparison = ???
}

To compare two instances of Column[String] (to see if they are equal) you want an implicit con­version of String to Column[String], so that you don't have to write:

Users.filter(_.firstName is ColumString("Bob"))

To do this you need to define the following:

implicit def stringToColumnStringConverter(s: String): Column[String] = ???

In this case, when you import your stringToColumnStringConverter, it will automatically convert any instances of String to Column[String] if it's required to do so. Since the is method only works on Column[String], the compiler will try to see if there is an implicit conversion available for the String “BoB,” so it can satisfy the method signature for is.

Implicit classes are a type safe solution that Scala provides for monkey patching (extending an existing class, or in Scala's case, a type without having to modify the existing source of the type). Let's try this by adding a replaceSpaceWithUnderScore method to a String.

object Implicits {
  implicit class StringExtensionMethods(string: String) {
    def replaceSpaceWithUnderScore = string.replaceAll(" ","_")
  }
}

Like the previous example, you need to import this class to make it available:

import Implicits._
"test this string".replaceSpaceWithUnderScore // returns test_this_string

Case Class, Tuples, and Case Object

Scala has a feature called case class, which is a fundamental structure to represent an immutable data. A case class contains various helper methods, which provide automatic accessors, and methods such as copy (return new instances of the case class with modified values), as well as implementations of .hashCode and equals.

case class User(id: Int, firstName: String, lastName: String)

User(1,"Bob","Elvin").copy(lastName = "Jane") // returns User(1,"Bob","Jane")

These combined features allow you to compare case classes directly. Case classes also provide a generic .toString method to pretty print the constructor values.

User(1,"Bob","Elvin").toString // returns "User(1,Bob,Elvin)"

Scala also has tuples, which work similarly to Python's tuples. A nice way to think of tuples is a case class that has its fields defined positionally (i.e., without its field name), and there is no restriction on a tuple requiring the same type for all of its elements. You can construct tuples by surrounding an expression with an extra set of parenthesis:

val userData = (5,"Maria", "Florence") //This will have type Tuple3
 [Int,String,String]

You can then convert between tuples and case classes easily, as long as the types and positions match:

val userData2: Tuple3[Int,String,String] = User.unapply(User(15,"Shelly","Sherbert")).get
val constructedUserData: User = User.tupled.apply(userData2) // Will be
User(15,"Shelly","Sherbert").

Tuples are a handy way to store grouped data of multiple types, and they can be destructured using the following notation:

val (id, firstName, lastName) = userData2

Note that tuples also provide an _index (where index is the position) and methods to access the elements of the tuple by position (in the example above, ._2 would return “Shelly”). We recommend that you use the deconstruction mentioned above, since it's clearer what the field is meant to be.

For internal and local use, tuples can be quite convenient due to not needing to define something like a case class to store data. However, if you find yourself constantly structuring/destructing tuples, and/or if you have methods returning tuples, it's usually a good idea to use a case class instead.

Abstract Class, Traits, and Sealed

In the previous chapter we discussed case classes. Apart from immutability (and other benefits), one of the primary uses of case classes is for creation of ADTs (known as Algebraic Data Types). Algebraic data types allow you to structure complex data in a way that is easy to decompose, and it is also known as the visitor pattern in Java. Here is an example of how you can model a video store:

sealed abstract class Hemisphere
case object North extends Hemisphere
case object South extends Hemisphere

sealed abstract class Continent(name: String, hemisphere: Hemisphere)

case object NorthAmerica extends Continent("North America", North)
case object SouthAmerica extends Continent("South America", South)
case object Europe extends Continent("Europe", North)
case object Asia extends Continent("Asia", North)
case object Africa extends Continent("Africa", South)
case object Australia extends Continent("Australia", South)

You can then easily use Pattern Matching (explained in greater detail in the next section) to extract data, and doing so looks similar to this:

val continent: Continent = NorthAmerica
continent match {
case Asia => println("Found asia")
case _ =>
}

You may also notice the keyword “sealed.” Sealed in Scala means that it's not possible for a class/case class/object outside of the file to extend what is sealed. In the example above, if Continent was defined in a file called Continent.scala, and in Main.scala you tried to do the following, Scala produces a compile error.

case object Unknown extends Continent

The advantage of sealed is that since the compiler knows all of the possible cases of a class/trait/object being extended, it's possible to produce warnings when pattern matching against the cases of the sealed abstract class. This also applies to Traits, not just sealed abstract classes.

Traits that allow Scala to implement the mixin pattern are another one of Scala's most powerful features. Traits, at a fundamental level, allow you to specify a body of code that other classes/traits/objects can extend. The only real limitation is that Traits can't have a primary constructor (this is to avoid the diamond problem). You can think of them as interfaces, except that you can provide definition for certain methods that you wish (and you can extend as many traits as you want).

A good use case for a trait is in a web framework, where traits are often used as a composition model for routes. Suppose you have trait defined as the following:

trait LoginSupport {self: Controller =>
       lazy val database: Database
       def login(userId) = {
            //Code dealing with logging in goes here
            afterLogin()
}
def logout() = {
      //Code dealing with logging out goes here
}
def afterLogin: Unit = {
}
}

Here a trait is defined that allows you to mixin login/logout functionality, but there are a few interest points here. The first is the self: Controller =>. This dictates that only a class of type Controller can extend the LoginSupport trait. Furthermore, there is a reference to this type through the self variable. This is actually an example of inversion of control, which is a basic technique needed to do simple DI (Dependency Injection) in Scala. This form of DI is statically checked, and doesn't need any dependency on external libraries, or features like macros.

The next important thing to note is the val database: Database. It's up to the class/trait/object extending LoginSupport to provide an implementation of database, which is ideally what you want (the LoginSupport trait shouldn't need to know how the database is being instantiated).

def login and def logout provide implementations for login and logout respectively. You then have an implementation of afterLogin(), which is called after you login() a user. Now let's assume you have a controller, or something like:

class ApplicationController(implicit val database: Database) extends LoginSupport {self:
Controller =>
}

Inside this class, you now have access to the login, logout, and afterLogin methods. Doing just the above however, would generate a compile error, since you haven't defined the database. Using an assumption that the database is being passed into the ApplicationController (let's say implicitly), you can do this:

class ApplicationController(implicit val database: Database) extends LoginSupport
{
}

You can provide an instance of the database as a constructor for ApplicationController, and it will be used by the LoginSupport. Alternatively, you can do this:

class ApplicationController2 extends LoginSupport {self: Controller =>
lazy val database: Database = Config.getDb
}

Similar to extending in Java classes, you can actually override one of these methods. In this case you can execute something after the user logins:

class ApplicationController3(implicit val database: Database) extends LoginSupport{self:
Controller =>
override def afterLogin() = Logger.info("You have successfully logged in!")
}

As you can see, traits are incredibly flexible. They allow you to cleanly split responsibility (i.e., what is implemented by the trait versus what is needed, but not implemented).

Statements Are Expressions

In Scala, any statement is also an expression. This is particularly powerful, since it represents a consistent way of working with branching of expressions (especially when combined with pattern matching as described before).

import scala.concurrent.Future
val parameter: Option[String] = ???
val httpCall: Future[String] = parameter match {
case Some(s) => Http.get("/api/doSomething/$s")
case None => Future("No parameter supplied")
}

The important thing to note here is that you are making sure that the return result of the statement is of type Future (so you can reuse this as a proper value later on).

String Interpolation

String interpolation provides a performant, concise, and typesafe way to print out values in the middle of string literals. The basic way to use the $ is to print the value of a variable:

s"the value of this variable is $s"

It's also possible to use block syntax so you can interpolate expressions, and not just values:

log.info(s"The id of the current user is ${user.id}")

Scala Collections, immutable and mutable

In the previous example, you can see the usage of methods like .map and .flatMap. These are actually fundamental patterns in functional programming, and they are used frequently in Scala as part of its collection framework. Scala collections are one of the few languages that provide a generic, strongly/statically typed framework for collections that also deal with type transformations. Let's start off with one of the most fundamental types in Scala, the List.

A List in Scala represents an immutable List, whereas a Seq represents an arbitrary sequence (can be mutable or immutable). Below is an example of how to use list:

val l = List(3,6,2342,8)

The type of this expression is List[Int]. One thing to note is that you can use the Seq constructor like so:

val s = Seq(3,6,2342,15)

Seq's default constructor is an immutable List, so in fact these expressions are equal. However, as stated before, a Seq can represent any sequence whereas a List is much more strict.

def listLength(l: List[_]) = l.length
def sequenceLength(s : Seq[_]) = s.length

It is perfectly legitimate to pass any sequence into sequenceLength (this can mean a Vector, a mutable list, or even a String), however, if you try to pass these types in listLength, you get a compile error. This is very powerful, as it allows you to specify the required granularity that is needed for collections, but it can also be dangerous. Consuming a list, while doing the map that is mutable versus immutable, can have unintended consequences.

.map allows you to apply an anonymous function to every element in a collection, with the item being replaced with the returning value of that anonymous function.

val l = List(3,6,2342,8)
l.map(int => int.toString) // Result is List("3","6","2342","8")

The example above converts every number to a String, which shows you how Scala on a simple level deals with converting types from within a collection (in this case Int -> String). One of the great things about the Scala collection library is that it provides implicit conversions that allow you to do complex transformations.

val m = Map(
"3" -> "Bob",
"6" -> "Alice",
"10" -> "Fred",
"15" -> "Yuki"
)

This Map will have the type Map[String,String]. However, let's say that you want to convert the keys to a String, while at the same time splitting out the names into its characters (i.e. Array[Char]).

A first naive solution to the problem can be:

val keys = m.keys.map{key => key.toInt}.to[List
val values = m.values.map{name => name.toCharArray}
(keys zip values).toMap

As you can see, this attempt is quite wordy, and it's also inefficient. You have to manually get the keys/values out of the map and transform them. Then you have to manually zip the keys with the values and convert them to a map. A more idiomatic solution is:

m.map{case (key,name) => key.toInt -> name.toCharArray }

This version is definitely more readable and succinct than the former, but you may be wondering how this works behind the scenes. Below is the definition of map from the Scala collections library.

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That

While this looks quite complex, the thing to note here is the implicit bf: CanBuildFrom[Repr, B, That]. This brings an implicit CanBuildFrom, which allows the Scala collection library to transform between different types to produce the desired results.

In this case, when you call the .map on the Map[String], the argument to the anonymous function is actually a tuple (which you destruct with the case statement).

m.map{x => …} // x is of type Tuple[String,String], with the first String being
  a key, and the second value
m.map{case (key,value) => … } // Deconstruct the Tuple[String,String
  immediately. key is of type String, as is value

If you return a tuple in the anonymous function that you place in map, CanBuildFrom will handle the conversion of Tuple2 as a key-value pair for the Map you originally operated off. The -> syntax you noticed earlier is actually an alias to construct a tuple:

implicit final class ArrowAssoc[A](private val self: A) extends AnyVal {
    @inline def -> [B](y: B): Tuple2[A, B] = Tuple2(self, y)
    def →[B](y: B): Tuple2[A, B] = ->(y)
}

In other words, key.toInt -> name.toCharArray is the same as (key.toInt,name.toCharArray). This means the return type of {case (key,name) => key.toInt -> name.toCharArray } is Tuple2[Int,Char[Array]], so all that happens is you go from Map[String,String] to Map[Int,Array[Char]] in the final expression.

You may ask at this point, what would happen if you return a completely different type, such as if you return an Int instead of a Tuple2[A,B] (where A and B are arbitrary types). Well, it so happens that the map has its (key,value) entry replaced with just a value, so you end up converting from a Map to an Iterable.

This means that m.map{case (_,value) => value } is the same as m.values, and m.map{case (key,_) => key } is the same as m.keys. A lot of these powerful transformations are possible due to CanBuildFrom, so you can implement equivalent functionality in other strongly, statically typed languages. This needs to be implemented into the actual compiler (in Scala, the collection is a standard Scala library that is included by default in the Scala distribution).

For Comprehension

You may have noticed earlier that when you composed map's and flatMap's, you end up with undesirable nesting (i.e., a horizontal pyramid). for comprehension is a very powerful feature to deal with such issues.

import scala.util._

def firstTry: Try[String] = Success { "first response" }
def secondTry(string: String): Try[Int] = Failure { new
IllegalArgumentException(s"Invalid length ${string.length}")
}
def finalTry(int: Int): Try[String] = Success { int.toString }


firstTry.map{result =>
  s"value from firstResult: $result"
}.flatMap{anotherResult =>
  secondTry(anotherResult).map{finalResult =>
    finalTry(finalResult).map(_.toUpperCase)
  }
}

The equivalent for comprehension for this statement would be:

for {
       result <- firstTry
       anotherResult = s"value from firstResult: $result"
       secondResult <- secondTry(anotherResult)
       finalResult <- finalTry(secondResult)
} yield finalResult.uppercase

The for comprehension has completely flattened out the above comprehension, making the intention very clear. for comprehension also provides syntactic sugar over filter/withFilter. A good example of this is shown using the Range class:

for (i <- 1 to 10000 if i % 2 == 0 ) yield i

This provides you with the all of the even numbers up to 10,000. The equivalent without the for comprehension is:

 (1 to 10000).withFilter(i => i % 2 == 0)

AnyVal, AnyRef, Any, and the Type Hierarchy

Unlike languages like Java and C, Scala makes a specific distinction between value's (also known as primitive types) and references in the type system generically. This allows you to specify your own custom values (in a limited fashion).

An AnyVal in Scala represents a value that is not boxed, i.e., they are represented as actual values. Common types that inherit AnyVal include number types (Int, Long, Double, and Float) as well as other types like Boolean. Since the memory representation of these types is often very small, it's much more efficient to store just the actual value in the host system, rather than a reference to the value.

Since Scala 2.10, you can define your own AnyVal types by extending the AnyVal class. Previously in the implicit section of this chapter we defined an ApiKey class, and the definition is repeated below.

case class ApiKey(id: String)

If you want to turn it into a value type, simply make it extend AnyVal:

case class ApiKey(id: String) extends AnyVal

Now whenever ApiKey is instantiated, you won't get a performance penalty due to boxing, yet you still have the benefits of treating ApiKey as a different type. You can write functions that take ApiKey, instead of having to deal with String.

There are limitations when it comes down to using AnyVal (http://docs.scala-lang.org/overviews/core/value-classes.html#limitations), and these limitations are mainly due to the underlying host (in this case, the JVM).

As opposed to AnyVal, Scala also has the concept of AnyRef, which represents a reference to an object. Essentially any instantiated variable that isn't an AnyVal has to be an AnyRef (either directly, or indirectly by the type hierarchy). One notable difference with AnyRefs is how to treat both equality and identity. Since AnyRef stores a reference to either a value or another object, rather than the actual value itself, there are different ways to treat equality. Typically, languages such as C and Java use reference equality to deal with the comparison of non-primitive types, which often means methods have to be separately defined to deal with equality by its contents (also known as deep or structural equality).

Similarly, methods often need to be defined to allow an efficient representation of the reference as a value (this is known as hashCode in Java).

In Scala, as in other functional languages such as ML and Haskell, deep equality is used by default for comparison with structures such as case classes, rather than just comparing whether the two objects have the same reference. The same also applies for hashCode.

case class Example(s: String)

Example("test") == Example("test") // returns true

val a = Example("test")
val b = Example("test")

a == b // Also returns true

class Example2(s:String)

val c = new Example2("test")
val d = new Example2("test")

c == d // Returns false

Finally, you have the Any type, which basically denotes that the type can be either a reference or a value. Any is the supertype of every other type in Scala (that is, everything can be of type Any). This in stark contrast to Java, which although it has an Object type, it doesn't have a type to represent values.