c# barcode generator library open source Type-Safe Fun in Font

Painting DataMatrix in Font Type-Safe Fun

But, oh how we can have some type-safe fun. We can find the id and name columns matching everyone whose name is David and whose id is 44. The type inferencer does the right thing and knows that the return type is a Tuple2[(Int, String)].

MyTable.find(MyTable.id ~ MyTable.name, By(MyTable.name, "David"), By(MyTable.id, 44), OrderBy(MyTable.name, Ascending)) match { case (_, name) :: _ => name.length // name is a String case _ => }

MyTable.find(MyTable.columns, By(MyTable.id, 33)) match { case (_, name, date) :: _ => name.length; date.getTime case _ => }

Pretty neat, huh We ve got the type safety of Scala with very readable library consumer code. But how type-safe is it Let s define a second table and see what happens when we try to mix things up.

class val val val val MyTable2 extends Table[MyTable2] with ConnectionSupplier { table = "mytable" id = IntColumn("id") name = StringColumn("name") birthday = DateColumn("birthday")

type ColumnTypes = (Int, String, Date) def columns = id ~ name ~ birthday } object MT2 extends MyTable2

We ve got MT2, which looks just like MyTable. Will the compiler let us build a query partially from MyTable and MT2 No.

MyTable.find(MyTable.name ~ MyTable.id, OrderBy(MT2.name, Ascending))

Query.scala:256: error: type mismatch; found : MT2.StringColumn required: BasicColumn[MyTable, _] MyTable.find(MyTable.name ~ MyTable.id, OrderBy(MT2.name, Ascending)) ^

MyTable.find(MyTable.name ~ MyTable.id, By(MyTable.name, 33))

Query.scala:258: error: no implicit argument matching parameter type (Int) => String was found. MyTable.find(MyTable.name ~ MyTable.id, By(MyTable.name, 33)) ^

In this section, we ve seen how Scala s type system provides us a very powerful mechanism for defining the rules for passing parameters. We were able to go through a lot of work to create a library that was complex underneath but simple to use. Let s go on to see a little more about how types and class hierarchies work in Scala.

Variance is an important and challenging concept. It defines the rules by which parameterized types can be passed as parameters. In the beginning of the chapter, we showed how passing a String[] (Java notation) to a method expecting an Object[] can cause problems. Java allows you to pass an array of something to a method expecting an array of something s superclass. This is called covariance. On the surface, this makes a lot of sense. If you can pass a String to a method expecting an Object, why can t you pass an Array[String] (Scala notation) to a method expecting an Array[Object] Because Array is mutable: it can be written to in addition to being read from, so a method that takes an Array[Object] may modify the Array by inserting something that cannot be inserted into an Array[String].

Defining the type variance for type parameters allows you to control how parameterized types can be passed to methods. Variance comes in three flavors: invariant, covariant, and contravariant. Type parameters can be individually marked as covariant or contravariant and are by default invariant.

In Scala, Array[T] is invariant. This means that you can only pass an Array[String] to foo(a: Array[String]) and that you can only pass an Array[Object] to bar(a: Array[Object]). This ensures that what is read from or written to the array is something of the correct type. So, for anything that s mutable, the type parameter should be invariant. You do this by doing nothing with the type parameter. So, let s define an invariant class:

class Holder[T](var data: T)

The class holds data of type T. Let s write a method:

scala> def add(in: Holder[Int]) {in.data = in.data + 1}

scala> val h = new Holder(0)

Because the add method expects an Int to come out of Holder and puts an Int back into the Holder, the type of the Holder must be invariant. That does not mean that invariant containers lose their ability to hold subclasses of their declared type. A Holder[Number] can