Daily scala

This is a continuation of post: Variant Positions 1

...

My first attempt at the Verified was to make it a mutable object (my Java tourettes kicking in). But it cannot be covariant and mutable. Look at the code to see why:

1. class Verified[+A <: V,V](assertion : (V) => Boolean, private var value : A){
2.     assert(assertion(value))
3.     
4.     def a = value
5. // update is illegal.  See the example below
6.     def update[ B >: A <: V](a : B) = value = a
7. }
8. def notNull(obj : AnyRef) = obj != null
9. val v = new Verified(notNull, "hi")
10. /*
11. Up to this point everything looks ok but the next line
12. will assign an object to value which is a reference to a String
13. */
14. v update (new Object())

For Verified to be mutable A must be invariant. If you look at the Mutable collections in Scala they are all invariant.

Here is an interesting example of both invariant and covariant type parameters in a class hierarchy:

1. scala> class X[+A](val x :A)
2. defined class X
3. scala> class Y[A](var a: A) extends X[A](a)
4. defined class Y
5. scala> val x: X[Any] = new Y[String]("hi")
6. x: X[Any] = Y@1732a4df
7. scala> x.asInstanceOf[Y[String]].a="ho"

This example is perfectly legal because no matter how X[Any] is used no illegal assignment in Y can occur. The interesting thing is that the object can be used in covariant usecases when only X is required. This is now the collections in Scala can work.

Here is a little example of collections invariance and covariance in action. In List the parameter is covariant but in Buffer it is invariant

1. scala> def printList(l : List[Any]) = print(l mkString " :: ")
2. printList: (l: List[Any])Unit
3. scala> val buffer = Buffer(1,2,3)
4. buffer: scala.collection.mutable.Buffer[Int] = ArrayBuffer(1, 2, 3)
5. scala> printList(buffer)
6. 1 :: 2 :: 3
7. /*
8. ++ is part of Iterable.  Since Iterable is covariant ++ 
9. returns a new buffer it does not modify the existing buffer
10. All mutators are only defined on invariant traits
11. */
12. scala> buffer ++ List(4)
13. res16: scala.collection.mutable.Buffer[Int] = ArrayBuffer(1, 2, 3, 4)
14. scala> res16 eq buffer
15. res17: Boolean = false
16. /*
17. buffer defines += to add an element to the buffer
18. so res27 is the same buffer with an extra element
19. */
20. scala> buffer += 10
21. res27: buffer.type = ArrayBuffer(1, 2, 3, 10)
22. scala> res27 eq buffer
23. res28: Boolean = true

An additional topic on variance to finish up the major points on the topic. The previous two posts:

• In- and Co- variance of type parameters
• Contravariance

contain required information for following this post.

In-, co- and contra- variance are the three types of variance expressible in Scala. I showed how this affects assignments and arguments being pass to methods in the last two topics. This looks at how the different types of variance influences how classes can be defined. In the last post we saw how the compiler complained about a method definition in a covariant class because the compiler recognized that such a definition was inherently dangerous and must be prohibited. The example was:

1. scala> class Output[+A] {def write(a : A) = () /*do write*/ }
2. < console>:5: error: covariant type A occurs in contravariant position in type A of value a
3.        class Output[+A] {def write(a : A) = () /*do write*/ }
4.                                    ^

For an class like Output it does not make sense to have A be covariant so we changed A to be contravariant. However suppose we have a collection type class.

1. class Verified[+A] (assertion : (A) => Boolean, value : A){
2.     assert(assertion(value))
3.     
4.     def a = value
5.     def a_=(a : A) = new Verified(assertion, a)
6. }

The previous definition is not legal because value and a in the parameter of a_= "occur in a contravariant position." What to do? Making A contravariant isn't an option:

1. class Verified[+A <: V,V](assertion : (V) => Boolean, val value : A){
2.     assert(assertion(value))
3. /*
4. this is the key.  Restrict possible types of
5. A Since B is a super (or equal) type of A
6. */
7.     def update[ B >: A <: V](a : B) = new Verified(assertion, a)
8. }
9. // example useage
10. scala> def notNull(obj : AnyRef) = obj != null
11. notNull: (obj: AnyRef)Boolean
12. scala> val v = new Verified(notNull, "hi")
13. v: Verified[java.lang.String,AnyRef] = Verified@307b37df
14. scala> val newV = v update (new Object())
15. newV: Verified[java.lang.Object,AnyRef] = Verified@36f72f09
16. // 3 is not legal because the type parameter 'V' is AnyRef.  Int is a subclass of Any NOT AnyRef
17. scala> val newV = v update (3)           
18. < console>:8: error: inferred type arguments [Any] do not conform to method update's type parameter bounds [B >: java.lang.String <: AnyRef]
19.        val newV = v update (3)
20.                   ^

In Java most parameterized types are considered to be "invariant". What does that mean? Here is an example to explain:

1. /*
2. This is an example of a parameterized class that with an invariant parameter B
3. In both Scala and Java parameters are invariant by default.
4. */
5. scala> class Invariant[B]
6. defined class Invariant
7. scala> var x : Invariant[Object] = new Invariant[Object]
8. x: Invariant[java.lang.Object] = Invariant@2e0c5575
9. /*
10. Note: Invariant[String] cannot be assigned to Invariant[Object]
11.       even though logically it seems like it should be.
12.       This is the effect of invariance.  Covariant parameters do not have
13.       this restriction.
14. */
15. scala> var x : Invariant[Object] = new Invariant[String]
16. < console>:6: error: type mismatch;
17.  found   : Invariant[String]
18.  required: Invariant[java.lang.Object]
19.  var x : Invariant[Object] = new Invariant[String]
20.                              ^
21. scala> class Sub[A] extends Invariant[A]   
22. defined class Sub
23. /*
24. Since Sub is a subclass of Invariant it can be assigned
25. (but not Sub[String])
26. */
27. scala> val x : Invariant[Object] = new Sub[Object]
28. x: Invariant[java.lang.Object] = Sub@26ced1a8

Assignment compatibility has multiple dimensions: the object type and the types of the parameters. Unlike object type the compatibility of the type-parameters can be covariant, contravariant and invariant. Java has invariant parameters and that is demonstrated by the previous example. Covariant parameters allow subclassing. Contravariant parameters need their own topic.

1. // The '+' indicates the parameter is covariant
2. scala> class Covariant[+B]
3. defined class Covariant
4. scala> var x : Covariant[Object] = new Covariant[Object]
5. x: Covariant[java.lang.Object] = Covariant@315cb235
6. // Now this is legal
7. scala> var x : Covariant[Object] = new Covariant[String]
8. x: Covariant[java.lang.Object] = Covariant@26e2e276
9. /*
10. Warning: The following is not legal because 
11.          you cannot supply an invariant parameter 
12.          with a covariant value.
13. */
14. scala> class Sub[+A] extends Invariant[A]
15. < console>:7: error: covariant type A occurs in invariant position in type [+A]Invariant[A] with ScalaObject{def this(): Sub[A]} of class Sub
16.        class Sub[+A] extends Invariant[A]
17.              ^
18. scala> class Sub[+A] extends Covariant[A]
19. defined class Sub
20. scala> class Sub[A] extends Covariant[A] 
21. defined class Sub