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