Methods of PartialFunction object

This topic looks at the functionality provide in the object PartialFunction.

This example uses Scala 2.8 which I believe is required.

Only two methods are focused on. PartialFunction.cond and PartialFunction.condOpt.
As per request the signature for said methods are:

1. def cond[T](x: T)(pf: PartialFunction[T, Boolean]): Boolean
2. def condOpt[T, U](x: T)(pf: PartialFunction[T, U]): Option[U]

Now for some examples:

1. scala>  import PartialFunction._
2. import PartialFunction._
4. scala> def strangeConditional(other: Any): Boolean = cond(other) {
5.      |  case x: String if x == "abc" || x == "def"  => true
6.      |  case x: Int => true
7.      | }
8. strangeConditional: (other: Any)Boolean
10. scala> strangeConditional("abc")
11. res0: Boolean = true
13. scala> strangeConditional("hello")
14. res1: Boolean = false
16. scala> strangeConditional(3)      
17. res2: Boolean = true
19. scala> def onlyInt(v: Any): Option[Int] = condOpt(v) { case x: Int => x }
20. onlyInt: (v: Any)Option[Int]
22. scala> onlyInt("hi")
23. res3: Option[Int] = None
25. scala> onlyInt(3)
26. res4: Option[Int] = Some(3)
28. scala> import util.control.Exception.catching
29. import util.control.Exception.catching
31. scala> object IntNum { 
32.      |  val number = catching(classOf[NumberFormatException])
33.      |  def unapply(x : Any) = condOpt(x) {
34.      |      case x : Int => x
35.      |      case y : String if number.opt(y.toInt).isDefined => y.toInt
36.      |    }
37.      | }
38. defined module IntNum
40. scala> 1 match { case IntNum(x) => println(x+" i win!")}   
41. 1 i win!
43. scala> 3 match { case IntNum(x) => println(x+" i win!")}
44. 3 i win!

=>? type alias for PartialFunction

A big thanks to Ben Jackman for this tip.

His tip cleans up the examples in post Chaining Partial Functions with orElse
The secret is to define the type alias type =>?[-A, +B] = PartialFunction[A, B]. This alias may be added to Predef in the future but until it is you can add it yourself.

1. scala> type =>?[-A, +B] = PartialFunction[A, B]
2. defined type alias $eq$greater$qmark
4. scala> val i : (Any =>? Unit) = {case x:Int => println("int found")}
5. i: =>?[Any,Unit] = < function1>
7. scala> val j : (Any =>? Unit) = {case x:Double => println("Double found")}
8. j: =>?[Any,Unit] = < function1>
10. scala> val * : (Any =>? Unit) = {case x=> println("Something else found")}
11. *: =>?[Any,Unit] = < function1>
13. scala> (i orElse j orElse *)(1)
14. int found
16. scala> (i orElse j orElse *)(1.0)
17. Double found
19. scala> (i orElse j orElse *)(true)
20. Something else found
22. scala> def =>?[A, B](id : A =>? B) = id
23. $eq$greater$qmark: [A,B](id: =>?[A,B])=>?[A,B]
25. scala> ( =>?[Any, Unit]{case s : String => println("String found")} orElse j orElse *)("hello")
26. String found

Chaining Partial Functions with orElse

PartialFunctions are extremely valuable Scala constructs that are used in many APIs. Commonly you will encounter the pattern:

1. obj match {
2. case "Val" => // do something
3. case _ => // handle all other cases
4. }

It is intuitive and obvious how to share the code of the right hand side if the case statement by factoring that code out to a method. But would it not be useful to be able to factor out an entire case statement (PartialFunction) and later chain them together as needed?

This is indeed possible and very easy to do:

1. /*
2. We need to declare Partial Functions so to add brevity I am adding this alias
3. */
4. scala> import scala.{PartialFunction => PF}
5. import scala.{PartialFunction=>PF}
7. /*
8. You have to explicitly declare the type because the type inferencer cannot know what type of PartialFunction to create
9.  
10. A PartialFunction is Strictly type so some functions can only be used on Ints for example
11. */
12. scala> val i : PF[Any, Unit] = {case x:Int => println("int found")}
13. i: PartialFunction[Any,Unit] = < function1>
15. scala> val j : PF[Any, Unit] =  {case x:Double => println("Double found")}
16. j: PartialFunction[Any,Unit] = < function1>
18. scala> val * : PF[Any, Unit] =  {case x=> println("Something else found")}
19. *: PartialFunction[Any,Unit] = < function1>
20. /*
21. one might think that you can do:
22. 1 match (i orElse j orElse *)
23. but in fact (i orElse j orElse *) forms a PartialFunction not a pattern so cannot be used with match.  Instead it must be used as a function
24. */
25. scala> (i orElse j orElse *)(1)
26. int found
28. scala> (i orElse j orElse *)(1.0)
29. Double found
31. scala> (i orElse j orElse *)(true)
32. Something else found
34. /*
35. for specific cases it is possible to chain the an anonymous partial function with the common function
37. This is not so nice so it is probably best to declare a val instead of inline like this
38. */
39. scala> (({case s:String => println("String found")}:PF[Any,Unit]) orElse j orElse *)("hello")
40. String found

For another example of chaining PartialFunctions the Akka tutorial has a good example in the ChatServer trait: http://jonasboner.com/2010/01/04/introducing-akka.html

And Case Statements

Recently I encountered a good question on Stack Overflow about matching.
http://stackoverflow.com/questions/2261358/pattern-matching-with-conjunctions-patterna-and-patternb.

As mentioned in an earlier post Matching with Or case expressions suppose 'or' expression combination using the '|' character. However 'and' combinations are not possible.

One solution is to build an && extractor object as follows:

1. scala> case object && {  def unapply[A](a: A) = Some((a, a))}
2. defined module $amp$amp
4. scala> object StartsWith {  def unapply(s: String) = s.headOption}
5. defined module StartsWith
7. scala> object EndsWith {  def unapply(s: String) = s.reverse.headOption}
8. defined module EndsWith
10. scala> "foo" match {  case StartsWith('f') && EndsWith('o') => println("f*o") }
11. f*o

Note: this is a scala 2.7 solution Scala 2.8 can be used to improve the EndsWith extractor by using the method lastOption instead of s.reverse.headOption.

Self Annotation vs inheritance

At first glance the "sself annotation" declaration seems similar to extending another class. (For a look at self annotations read the topic: Self Type.) They are completely different but the comparison is understandable since both of them provide access to the functionality of referenced class.

For example both of the following compile:

1. class Base {
2.   def magic = "bibbity bobbity boo!!"
3. }
5. trait Extender extends Base {
6.   def myMethod = "I can "+magic
7. }
9. trait SelfTyper {
10.   self : Base => 
11.   
12.   def myMethod = "I can "+magic
13. }

But the two are completely different. Extender can be mixed in with any class and adds both the "magic" and "myMethod" to the class it is mixed with. SelfType can only be mixed in with a class that extends Base and SelfTyper only adds the method "myMethod" NOT "magic".

Why is the "self annotations" useful? Because it allows several provides a way of declaring dependencies. One can think of the self annotation declaration as the phrase "I am useable with" or "I require a".

The following example demonstrates one possible reason to use self annotations instead of extend.

Note: These examples can be pasted into the REPL but I have shown that here because it would make the examples too long.

1. import java.io._
2. import java.util.{Properties => JProps}
4. trait Properties {
5.   def apply(key:String) : String
6. }
8. trait XmlProperties extends Properties {
9.   import scala.xml._
10.   
11.   def xml(key:String) = Elem(null,key,Null,TopScope, Text(apply(key)))
12. }
14. trait JSonProperties extends Properties {
15.   def json(key:String) : String = "%s : %s".format(key, apply(key))
16. }
18. trait StreamProperties {
19.   self : Properties => 
20.   
21.   protected def source : InputStream
22.   
23.   private val props = new JProps()
24.   props.load(source)
25.   
26.   def apply(key:String) = props.get(key).asInstanceOf[String]
27. }
29. trait MapProperties {
30.   self : Properties =>
31.   
32.   protected def source : Map[String,String]
33.   def apply(key:String) = source.apply(key)
34. }
36. val sampleMap = Map("1" -> "one", "2" -> "two", "3" -> "three")
37. val sampleData = """1=one
38.                     2=two
39.                     3=three"""
41. val sXml = new XmlProperties() with StreamProperties{
42.               def source = new ByteArrayInputStream(sampleData.getBytes)
43.            }
44. val mXml = new XmlProperties() with MapProperties{
45.               def source = sampleMap
46.            }
48. val sJSon = new JSonProperties() with StreamProperties{
49.               def source = new ByteArrayInputStream(sampleData.getBytes)
50.             }
51. val mJSon = new JSonProperties() with MapProperties{
52.               def source = sampleMap
53.             }
55. sXml.xml("1")
56. mXml.xml("2")
57. sJSon.json("1")
58. mJSon.json("2")

The justification for using self annotations here is flexibility. A couple other solutions would be

1. Use subclassing - this is poor solution because there would be an explosion of classes. Instead of having 5 traits you would need 7 traits. Properties, XmlProperties, JSonProperties, XmlStreamProperties, XmlMapProperties, JsonStreamProperties and JsonMapProperties. And if you later wanted to add a new type of properties or a new source like reading from a database then you need 2 new subclasses.
2. Composition - Another strategy is to use construct the XmlProperties with a strategy that reads from the source. This is essentially the same mechanism except that you need to build and maintain the the dependencies. It also makes layering more difficult. For example:
   
   1. trait IterableXmlProperties {                                            
   2.     self : MapProperties with XmlProperties => 
   3.     def xmlIterable = source.keySet map {xml _}
   4.   }
   5.   
   6.   new XmlProperties with MapProperties with IterableXmlProperties {def source = sampleMap}

The next question that comes to mind is why use extends then if self annotation is so flexible? My answer (and I welcome discussion on this point) has three points.

1. The first is of semantics and modeling. When designing a model it is often more logical to use inheritance because of the semantics that comes with inheriting from another object.
2. Another argument is pragmatism.
   Imagine the collections library where there is no inheritance. If you wanted a map with Iterable functionality you would have to always declare Traversable with Iterable with Map (and this is greatly simplified). That declaration would have to be used for virtually all methods that require both the Iterable and Map functionality. To say that is impractical is an understatement. Also the semantics of Map is changed from what it is now. The trait Map currently includes the concept of Iterable.
3. The last point is sealed traits/classes. When a trait is "sealed" all of its subclasses are declared within the same file and that makes the set of subclasses finite which allows certain compiler checks. This (as far as I know) cannot be done with self annotations.

Specs and Fixtures/Contexts

This topic revisits the Specs BDD testing library. It is a continuation of the previous post Specs BDD Testing Framework.

This topic will look at how to setup fixtures in Specs. This is only a sample to give a feeling of Specs a much more complete guide is available on the Specs website.

1. jeichar: git-src$ scala -classpath ~/.m2/repository/org/scala-tools/testing/specs/1.6.1/specs-1.6.1.jar
3. scala> import org.specs._
4. import org.specs._
6. /*
7. This example demonstrates before and after actions similar to what is found in XUnit.
8. */
9. scala> object mySpec extends Specification {           
10.      | "my system" should {
11.      | doFirst{println("before")}  // ran once
12.      | 
13.      | doBefore{println("before")} // ran for each test
14.      | doAfter{println("after")} // ran for each test
15.      | 
16.      | "test spec 1" in { println("test1"); 1 must_== 1}
17.      | "test spec 2" in { println("test2"); 1 must_== 2}
18.      | 
19.      | doLast{println("last")} // ran once
20.      | }}
21. defined module mySpec
23. scala> mySpec.main(Array())                             
24. Specification "mySpec"
25.   my system should
26. before
27. before
28. test1
29. after
30.   + test spec 1
31. before
32. test2
33. after
34. last
35.   x test spec 2
36.     '1' is not equal to '2' (< console>:14)
38. Total for specification "mySpec":
39. Finished in 0 second, 307 ms
40. 2 examples, 2 expectations, 1 failure, 0 error

Example using Contexts there many more examples at: Shared contexts

1. scala> import org.specs._
2. import org.specs._
4. /*
5. This specification uses contexts instead of before and after actions.
7. My personal preference is to use contexts because they are more flexible and can have names associated with them.  In addition contexts can be shared between specifications and multiple contexts can be used within a single specification.  This example is kept very simple for demonstration purposes
8. */
9. scala> object StackSpecification extends Specification {
10.      |   var list : List[Int] = _
11.      |   val empty = beforeContext(list = Nil)  
12.      |   val nonEmpty = beforeContext(list = List(1,2,3))
13.      |   
14.      |   "A full stack" definedAs nonEmpty should { 
15.      |     "size of 3" in {
16.      |       list must haveSize (3)
17.      |     }
18.      |   }
19.      |   "A stack" when empty should { 
20.      |     "is empty" in {
21.      |       list must beEmpty
22.      |     }
23.      |   }
24.      | }
25. defined module StackSpecification
27. scala> StackSpecification.main(Array())
28. Specification "StackSpecification"
29.   A full stack should
30.   + size of 3
32.   Total for SUS "A full stack":
33.   Finished in 0 second, 42 ms
34.   1 example, 1 expectation, 0 failure, 0 error
36.   A stack should
37.   + is empty
39.   Total for SUS "A stack":
40.   Finished in 0 second, 4 ms
41.   1 example, 1 expectation, 0 failure, 0 error
43. Total for specification "StackSpecification":
44. Finished in 0 second, 85 ms
45. 2 examples, 2 expectations, 0 failure, 0 error

Selection with Implicit Methods

This tip is a cool tip based on Daniel's Use Implicits to Select Types post. That post goes into more detail.

The idea is that depending on a given parameter of type T a particular type of object is required. There are several ways to do this. One would be to use matching to match the type T and create the correct object. Most likely the biggest draw back to matching is caused by type erasure. The following solution gets around that issue.

Two very interesting points.

1. Implicit methods do not require parameters. They can be selected based only on type parameters
2. Implicit methods are not subject to type erasure

1. // the base class we need
2. scala> abstract class X[T] { def id :Unit }
3. defined class X
5. /*
6. One of the types we need created.  It is the catch all case
7. */
8. scala> implicit def a[T] =new X[T] { def id =println("generic") }
9. a: [T]X[T]
11. /*
12. A specific subclass for integers
13. */
14. scala> implicit def b =new X[Int] { def id =println("Int") }
15. b: X[Int]
17. /*
18. One simple usage.  The most specific implicit will be used to 
19. create the object to be passed to g.  
20. */
21. scala> def f[T](a :T)(implicit g :X[T]) = g.id
22. f: [T](a: T)(implicit g: X[T])Unit
24. scala> f(5)
25. Int
27. scala> f('c')
28. generic
30. /*
31. This example demonstrates how erasure is not an issue because 
32. the selection of the implicit is done at compile time so 
33. the correct type is selected.  If a match was used instead 
34. then a more complicated solution would be required
35. */
36. scala> def g[T](l:List[T])(implicit i:X[T]) = i.id          
37. g: [T](l: List[T])(implicit i: X[T])Unit
39. scala> g(List(1,2,3))
40. Int
42. scala> g(List("a",2,3))
43. generic

Structural Types: Multiple Methods and Type Aliasing

There are two more aspects related to structural typing that are useful to look at. Structural types with multiple methods and type aliases.

For background on this topic also look at:

• Introducing Structual Types
• Dynamic Calls Using Structural Types

Structural Types are not limited to defining a single method. In that regard they are very similar to interfaces without the binary incompatibility issues. However do not be fooled into thinking they are the same thing. For one reason reflection is used so performance can be an issue in certain cases and also interfaces/traits have semantics that structural types do not.

1. /*
2. Defining a types that has both a length and charAt method.  
4. Just a warning.  If you leave off the () after length this will not work.  This is not a bug.  Martin kindly left a comment on why it is not.
5. */
6. scala> def foreach(t : {def length():Int; def charAt(i:Int):Char}, f : Char => Unit) = {
7.      | 0 until t.length foreach {i => f(t.charAt(i))}  
8.      | }
9. foreach: (t: AnyRef{def length(): Int; def charAt(i: Int): Char},f: (Char) => Unit)Unit
11. // A string matches the structural type
12. scala> foreach ("hello", println _)
13. h
14. e
15. l
16. l
17. o

Pretty unexpected I would say. A feature of Scala which complements Structural types are type aliases. They are useful in many situations and one is with use with Structural Types:

1. /*
2. With type aliasing you can assign a structural type a name
3. */
4. scala> type IChar = {def length():Int
5.      |               def charAt(i:Int):Char}
6. defined type alias IChar
8. scala> def print( t : IChar) = 0 until t.length() foreach {i => println(t.charAt(i))}
9. print: (t: IChar)Unit
11. scala> print("gurk")
12. g
13. u
14. r
15. k

Dynamic calls using Structural Types

Using reflection can be a real pain in Java since the API is a Java API and consists of many gets and searches through collections not to mention so many exceptions that need to be handled. In Scala there is a wonderful way to clean up a reflective call down to a single line (assuming you don't want to worry about handling exceptions.) Here structural typing can really be a pleasure.

1. // I am assigning a string to an Any reference
2. scala> val s:Any = "hello :D"
3. s: Any = hello :D
5. // Any does not have a length method
6. scala> s.length
7. < console>:6: error: value length is not a member of Any
8.        s.length
9.          ^
11. /*
12. But I can cast it to a structural type with a length method
13. */
14. scala> s.asInstanceOf[{def length:Int}].length
15. res2: Int = 8

There are restrictions to this. For example implicits will not work:

1. /*
2. The method r is part of StringLike (or RichString in Scala 2.7) 
3. and there is an implicit conversion from String to RichString/StringLike.
4. The structural type does not try to apply the implicits because implicits are a
5. compile time artifact and that information is not kept at run time.  Perhaps this
6. will be added in the future but it is not present now.
7. */
8. scala> s.asInstanceOf[{def r:util.matching.Regex}].r
9. java.lang.NoSuchMethodException: java.lang.String.r()

More examples:

1. scala> val s:Any = "hello :D"
2. s: Any = hello :D
4. scala> s.asInstanceOf[{def charAt(x:Int):Char}].charAt(2)
5. res9: Char = l
7. /*
8. This is interesting.  The actual method returns Char, but Char is
9. compatible with Any so this cast works.
10. */
11. scala> s.asInstanceOf[{def charAt(x:Int):Any}].charAt(2) 
12. res10: Any = l
14. // Now lets test to see if that lenience is available for parameters:
15. scala> class X 
16. defined class X
18. scala> class Y extends X
19. defined class Y
21. scala> class T {
22.      | def x(x:X):Int = 1
23.      | }
24. defined class T
26. scala> val a:Any = new T()
27. a: Any = T@687c3b99
29. scala> a.asInstanceOf[{def x(x:X):Any}].x(new Y())
30. res11: Any = 1
32. /*
33. Ok so return values can be subclasses but not params
34. */
35. scala> a.asInstanceOf[{def x(x:Y):Any}].x(new Y())
36. java.lang.NoSuchMethodException: T.x(Y)
37. at java.lang.Class.getMethod(Class.ja

Use with care :-D

Introducing Structural Types

Structural types allows one to declare types based on the methods the type has. For example you could define a method that takes a class containing a close method. This is fairy analogous to duck-typing in dynamic languages. Except that it is statically enforced.

The main example used here was from a comment on the Code Monkeyism Blog. The commenter further explains that this example is in fact from Beginning Scala chapter 4 (which I would like to read but have not yet had the time.)

1. /*
2. A can be any object that has a close method.  
4. This is statically typed which makes some restrictions which are explained later
5. */
6. scala> def using[A <: {def close(): Unit}, B](param: A)(f: A => B): B = 
7.      | try {
8.      |     f(param)
9.      |   } finally {
10.      |     try {
11.      |        param.close()
12.      |     } catch { case _ => () }
13.      |   }
14. using: [A <: AnyRef{def close(): Unit},B](param: => A)(f: (A) => B)B
16. scala> using(new java.io.ByteArrayInputStream("hello world".getBytes)){ in => 
17.      | io.Source.fromInputStream(in) foreach (print)                          
18.      | }
19. hello world
21. scala> using(new java.io.ByteArrayInputStream("hello world".getBytes)){ in => 
22.      | io.Source.fromInputStream(in) mkString ""                              
23.      | }
24. res8: String = hello world

That is extremely powerful and the consequences will be visited more in the future. But because structural typing is statically enforced it is not quite as flexible as dynamic language's version of duck typing. For example you cannot do:

1. scala> val i:Any = new java.io.ByteArrayInputStream("hello world".getBytes)
2. i: Any = java.io.ByteArrayInputStream@145a25f3
4. /*
5. This does not work because 'i' is defined as type Any.  Not a type that is closeable.  
7. Casting can be used to get around this issue.  I will address that in its own post
8. */
9. scala> using(i){ in => 
10.      | io.Source.fromInputStream(in) mkString ""
11.      | }
12. < console>:8: error: inferred type arguments [Any,B] do not conform to method using's type parameter bounds [A <: AnyRef{def close(): Unit},B]
13.        using(i){ in =>

An alternative to the first using example is to use call by name to construct the closeable. The reason one might want to do that is because it allows currying of the method:

1. scala> def using[A <: {def close(): Unit}, B](param: =>A)(f: A => B): B = 
2.      | val closeable = param  // notice param is only referenced once
3.      | try {
4.      |     f(closeable)
5.      |   } finally {
6.      |     try {
7.      |        closeable.close()
8.      |     } catch { case _ => () }
9.      |   }
10. using: [A <: AnyRef{def close(): Unit},B](param: => A)(f: (A) => B)B
12. /*
13. if this was accessing a database a new connection would be made automatically each time this function was used
14. */
15. scala> val usingTheWorld = using[BStream,Int](new java.io.ByteArrayInputStream("hello world".getBytes))_
16. usingTheWorld: ((java.io.ByteArrayInputStream) => Int) => Int = < function1>
18. scala> usingTheWorld { s => io.Source.fromInputStream(s).length}  
19. res3: Int = 11
21. scala> usingTheWorld { s => io.Source.fromInputStream(s).getLines().length}
22. res5: Int = 0

Regex ReplaceAllIn

Note: Updated on Feb 13th for the newer API on Scala 2.8 trunk. (This is life on the bleeding edge, thanks Daniel).

A couple new methods have just been added to Scala 2.8 Regex. You will need to download a version of Scala 2.8 more recent than Scala2.8-Beta1.

The methods are related to replacing text using a regular expression and to say they are useful is an understatement. Lets take a look:

1. scala> val quote = """I don't like to commit myself about heaven and hell - you see, I have friends in both places. 
2.      | Mark Twain"""                                                                                                
3. quote: java.lang.String = 
4. I don't like to commit myself about heaven and hell - you see, I have friends in both places. 
5. Mark Twain
7. scala> val expr = "e".r    
8. expr: scala.util.matching.Regex = e
10. /* 
11. This first method is not new or is it interesting.  But the new methods are both related
12. so lets start with the basic form of replaceAllIn
13. */
14. scala> expr.replaceAllIn(quote, "**")
15. res1: String = 
16. I don't lik** to commit mys**lf about h**av**n and h**ll - you s****, I hav** fri**nds in both plac**s. 
17. Mark Twain
19. // this does the same thing
20. scala> quote.replaceAll("e","**")
21. res2: java.lang.String = 
22. I don't lik** to commit mys**lf about h**av**n and h**ll - you s****, I hav** fri**nds in both plac**s. 
23. Mark Twain
25. /*
26. Now things get interesting.  Using this form of replaceAllIn we can determine the replacement on a case by case basis.
28. It provides the Match object as the parameter so you have complete access to all 
29. the matched groups, the location of the match etc...
31. The method takes a Match => String function.  Very, very powerful.
32. */
33. scala> expr.replaceAllIn(quote, s => if(util.Random.nextBoolean) "?" else "*")
34. res5: String = 
35. I don't lik? to commit mys?lf about h?av?n and h?ll - you s*?, I hav? fri*nds in both plac*s. 
36. Mark Twain
38. /*
39. Another example using some of the matcher functionality
40. */
41. scala> expr.replaceAllIn(quote, m => m.start.toString)                        
42. res6: String = 
43. I don't lik11 to commit mys26lf about h37av40n and h48ll - you s5960, I hav68 fri73nds in both plac90s. 
44. Mark Twain
46. /*
47. Another crazy useful method is the replaceSomeIn.  It is similar to the replaceAllIn that takes a function except that the function in replaceSomeIn returns an Option.  If None then there is no replacement.  Otherwise a replacement is performed.  Very nice when dealing with complex regular expressions.
49. In this example we are replacing all 'e's start are before the 50th character in the string with -
50. */
51. scala> expr.replaceSomeIn(quote, m => if(m.start > 50) None else Some("-"))
52. res3: String = 
53. I don't lik- to commit mys-lf about h-av-n and h-ll - you see, I have friends in both places.
54. Mark Twain

Chaining Options with orElse

A simple but handy use for Option is to select the first valid option from a selection of possible choices. Sound vague? Well it is because it can be used in many different situations. The one presented here is: the program needs a directory that can be set by the user either as a system variable, and environment variable or the default value. The java code is a nightmare of if (xxx == null) statements. The Scala code is beautiful.

1. scala> val propsTemplates = Option(System getProperty "MVN_CREATOR_TEMPLATES")
2. propsTemplates: Option[java.lang.String] = None
4. scala> val envTemplates = Option(System getenv "MVN_CREATOR_TEMPLATES")
5. envTemplates: Option[java.lang.String] = None
7. scala> val defaultHome = Some(System getProperty "user.home")
8. defaultHome: Some[java.lang.String] = Some(/Users/jeichar)
10. /* 
11. chain the different options together in order of priority and get the value
13. I am taking a small liberty here because I am assuming that user.home is always available
14. */
16. scala> propsTemplates.orElse(envTemplates).orElse(defaultHome).get
17. res0: java.lang.String = /Users/jeichar
19. // alternative form:
20. scala> propsTemplates orElse envTemplates orElse defaultHome get
21. res1: java.lang.String = /Users/jeichar

Blocks within for-comprehensions

In another example of uniformity it is possible to use blocks within a for-comprehension when creating a generator or making an assignment. The basic form of a for-comprehension is

1. for {i <- generator 
2.      if guard
3.      j = assignment } yield result

The generator, guard, assignment and result are all expressions which means they can all be blocks or simple statements. Most commonly you will see them as simple statements:

1. scala> for {i <- 1 to 10
2.      |      if i % 2 == 0
3.      |      j = i } yield j
4. res50: scala.collection.immutable.IndexedSeq[Int] = IndexedSeq(2, 4, 6, 8, 10)

But since they are expressions they can be more complex:

1. scala> for {  
2.      |  i <- { 
3.      |     val start = nextInt(3)
4.      |     val end = nextInt(10)+start
5.      |     start to end
6.      |  }
7.      |  if {
8.      |    val cut = nextInt(3)+1
9.      |    i % cut == 0
10.      |  }
11.      |  j = {
12.      |    val x = i+1
13.      |    x / 2
14.      |  }
15.      |  }  yield {
16.      |    // do a debug println
17.      |    println(j)
18.      |  j
19.      |  }
20. 1
21. 1
22. 2
23. 3
24. res53: scala.collection.immutable.IndexedSeq[Int] = IndexedSeq(1, 1, 2, 3)

Temporary variables during object instantiation

In Java a common pattern with class constructors is to assign field values and often there are several intermediate values used for the calculation. If the code is ported to Scala the resulting class will have the intermediate values as fields, which take up space in the object. However the issue is easily worked around. Lets look at a couple examples.

Example 1: Assigning a single field

1. //  Java
2. import java.io.File
4. /** 
5. No real logic behind class.  But for some reason it needs the path of a tmp directory in the working directory
6. */
7. class OneAssignment {
8.   final String field;
9.   public OneAssignment() {
10.     File file = new File("tmp");
11.     if(!file.exists()) {
12.       file.mkdirs();
13.     }
14.     field = file.getAbsolutePath();
15.   }
16. }

In Scala the naive way to port this would be:

1. //  Scala
2. import java.io.File
3. class OneAssignment {
4.   val file = new File("tmp")
5.   if(!file.exists()) {
6.     file.mkdirs()
7.   }
8.   val field = file.getAbsolutePath()
9. }

Problem is that it has an extra field "file" now. The correct way to port this would be as follows:

1. //  Scala
2. import java.io.File
3. class OneAssignment {
4. /* 
5. notice that assignment is in a block so file is only visible within the block
6. */
7.   val field = {
8.     val file = new File("tmp")
9.     if(!file.exists()) {
10.       file.mkdirs()
11.     }
12.     file.getAbsolutePath()
13.   }
14. }

Example 2: Assigning multiple fields

1. //  Java
2. import java.io.File
4. /** 
5. Basically the same as last example but multiple fields are assigned
6. Notice that 2 fields depend on the temporary file variable but count does not
7. */
8. class MultipleAssignments {
9.   final String tmp,mvn_repo;
10.   find int count;
11.   public OneAssignment() {
12.     File file = new File("tmp");
13.     if(!file.exists()) {
14.       file.mkdirs();
15.     }
16.     tmp = file.getAbsolutePath();
17.     count = file.listFiles.length;
18.     
19.     File home = new File(System.getProperty("user.home"));
20.     mvn_repo = new File(home, ".m2").getPath();
21.   }
22. }

The Scala port:

1. //  Scala
2. import java.io.File
3. class MultipleAssignments {
4. /*
5. When multiple fields depend on the same temporary variables the fields can be assigned together from one block by returning a tuple and using Scala's matching to expand the tuple during assignment.  See previous topics on assignment for details 
6. */
7.   val (tmp,count) = {
8.     val file = new File("tmp");
9.     if(!file.exists()) {
10.       file.mkdirs();
11.     }
12.     val tmp = file.getAbsolutePath();
13.     val count = file.listFiles.length;
14.     (tmp, count)
15.   }
16.   val mvn_repo = {
17.     val home = new File(System.getProperty("user.home"));
18.     new File(home, ".m2").getPath();
19.   }
20. }

In some ways the Scala port is cleaner in that it splits the constructor up and decouples the dependencies between fields.