The Scala Option class and how lift uses it

If you come from an imperative (Java, Ruby) background, you'll probably recognize the following code:

x = someOperation
if !x.nil?
  y = someOtherOperation
  if !y.nil?
    doSomething(x,y)
    return "it worked"
  end
end
return "it failed"

Okay, so that's pseudo-code, but there are tons of operation, guard, operation, guard, blah blah constructs.

Further, null/nil are passed around as failures. This is especially bad when it's null, but it's pretty bad when it's nil.

In Java, null is a non-object. It has no methods. It is the exception to the statically typed rule (null has no class, but any reference of any class can be set to null.) Invoking a method on null has one and only one result: an exception is thrown. null is often returned from methods as a flag indicating that the method ran successfully, but yielded no meaningful value. For example, CardHolder.findByCreditCardNumber("2222222222")

Ruby has nil which is marginally better than null. nil is a real, singleton object. There's only one instance of nil in the whole system. It has methods. It is a subclass of Object. Object has a method called "nil?" which returns false, except the nil singleton overrides this method to return true. nil is returned much like null in Java. It's the "no valid answer" answer.

Scala does something different.

There's an abstract class, called Option. Options are strongly typed. They are declared Option[T]. This means an Option can be of any type, but once its type is defined, it does not change. There are two subclasses of Option: Some and None. None is a singleton (like nil). Some is a container around the actual answer. So, you might have a method that looks like:

def findUser(name: String): Option[User] = {
  val query = buildQuery(name)
  val resultSet = performQuery(query)
  val retVal = if (resultSet.next) Some(createUser(resultSet))
               else None
  resultSet.close
  retVal
}

Some, you've got a findUser method that returns either Some(User) or None. So far, it doesn't look a lot different than our example above. So, to confuse everyone, I'm going to talk about collections for a minute.

A really nice thing in Scala (yes, Ruby has this too) is rich list operations. Rather than creating a counter and pulling list (array) elements out one by one, you write a little function and pass that function to the list. The list calls the function with each element and returns a new list with the values returned from each call. It's easier to see it in code:

scala> List(1,2,3).map(x => x * 2)
line0: scala.List[scala.Int] = List(2,4,6)

The above code multiplies each list item by two and "map" returns the resulting list. Oh, and you can be more terse, if you want:

scala> List(1,2,3).map(_ * 2)
line2: scala.List[scala.Int] = List(2,4,6)

You can nest map operations:

scala> List(1,2,3).map(x => List(4,5,6).map(y => x * y))
line13: scala.List[scala.List[scala.Int]] = List(List(4,5,6),List(8,10,12),List(12,15,18))

And, you can "flatten" the inner list:

scala> List(1,2,3).flatMap(x => List(4,5,6).map(y => x * y))
line14: scala.List[scala.Int] = List(4,5,6,8,10,12,12,15,18)

Finally, you can "filter" only the even numbers from the first list:

scala> List(1,2,3).filter(_ % 2 == 0).flatMap(x => List(4,5,6).map(y => x * y))
line16: scala.List[scala.Int] = List(8,10,12)

But, as you can see, the map/flatMap/filter stuff gets pretty verbose. Scala introduced a "for" comprehension to make the code more readable:

scala> for (val x <- List(1,2,3);
     |      val y <- List(4,5,6);
     |      x % 2 == 0) yield x * y
line17: scala.List[scala.Int] = List(8,10,12)

Okay, but what does this have to do with Option[T]?

Turns out that Option implements map, flatMap, and filter (the methods necessary for the Scala compiler to use in the 'for' comprehension. Just as a side note, when I first encountered the phrase "'for' comprehension", I got scared. I've been doing programming for years and never heard of a "comprenhension" let alone a 'for' one. Turns out, that there's nothing fancy going on, but "'for' comprehension" is just a term of art for the above construct.

So, the cool thing is that you can use this construct very effectively. The first example is simple:

scala> for (val x <- Some(3);
     |      val y <- Some(4)) yield x * y
line18: scala.Option[scala.Int] = Some(12)

"That's nice, you just wrote a lot of code to multiply 3 by 4."

Let's see what happens if we have a "None" in there:

scala> for (val x <- Some(3);
     |      val y <- None) yield x * y
line20: scala.Option[scala.Int] = None

So, we get a "None" back. How do we turn this into a default value?

(for (val x <- Some(3); val y <- None) yield x * y) getOrElse -1
line21: scala.Int = -1

scala> (for (val x <- Some(3); val y <- Some(4)) yield x * y) getOrElse -1
line22: scala.Int = 12

Note that the "orElse" code is "passed by name". Put another way, that code is only executed if the "else" clause is valid.

In lift, I put this all together in the following way:

• methods that return request parameters return Option[String]
• finder methods on models (not find all, just the ones that return a single instance) return Option[Model]
• any method that would have returned a null if I was writing in Java returns an Option[T] in lift

That means you get code that looks like:

  def confirmDelete {
    (for (val id <- param("id"); // get the ID
          val user <- User.find(id)) // find the user                                                                          
     yield {
         user.delete_!
         notice("User deleted")
         redirectTo("/simple/index.html")
       }) getOrElse {error("User not found"); redirectTo("/simple/index.html")}
   }

There's no explicit guard/test to see if the "id" parameter was passed in and there's no explicit test to see if the user was found. If the id isn't supplied or the id doesn't match a user in the system, the "else" clause will execute.

Note also that this code is completely type-safe. While there was no explicit type declarations, the compiler was able to figure out what types the various objects were.

I hope this is an understandable introduction to Scala's Option class and 'for' comprehension and how lift makes use of these tools.