Scala generics: Int not conforming to Comparable?

Question

The following Scala declarations are OK:

trait Base[B <: Base[B,M,ID], M <: Meta[B,M,ID], ID <: Comparable[ID]] {
    // ...
}

trait Meta[B <: Base[B,M,ID], M <: Meta[B,M,ID], ID <: Comparable[ID]] extends Ordered[Meta[_,_,_]] {
    // ...
}

trait BaseWithID[B <: BaseWithID[B,M,ID], M <: Meta[B,M,ID], ID <: Comparable[ID]] extends Base[B,M,ID] with Ordered[B] {
    // ...
}


trait BaseWithIntID[B <: BaseWithIntID[B,M,ID], M <: MetaWithIntID[B,M,ID], ID <: Comparable[ID]] extends BaseWithID[B,M,ID] {
    // ...
}

trait MetaWithIntID[B <: BaseWithIntID[B,M,ID], M <: MetaWithIntID[B,M,ID], ID <: Comparable[ID]] extends Meta[B,M,ID] {
    // ...
}

But the following two are not:

trait BaseWithIntID[B <: BaseWithIntID[B,M], M <: MetaWithIntID[B,M]] extends BaseWithID[B,M,Int] {
    // ...
}

trait MetaWithIntID[B <: BaseWithIntID[B,M], M <: MetaWithIntID[B,M]] extends Meta[B,M,Int] {
    // ...
}

The difference is that I removed the ID type parameter in BaseWithIntID and MetaWithIntID, and specified Int explicitly in their respective base traits. But this does not compile, so does that mean that Int is not Comparable in Scala? If it is, what am I doing wrong? I tried Ordered instead of Comparable, and it made not difference.

I'm using Eclipse, and as usual, the error messages are unhelpful:

type arguments [B,M,Int] do not conform to trait BaseWithID's type parameter bounds [B <: BaseWithID[B,M,ID],M <: Meta[B,M,ID],ID <: java.lang.Comparable[ID]]

It just says that something is wrong, but not which type parameter is wrong, and why. Looking at this question, I thought I could try "ID <% Comparable[ID]" instead, but that is not legal in a trait declaration.

Actually, this does not work either (with the same error message):

trait TestBase extends BaseWithID[TestBase,TestMeta,Int]

trait TestMeta extends Meta[TestBase,TestMeta,Int]

Answer 1

Int is indeed not comparable in scala, certainly because it is in fact implemented as java int, not java.lang.Integer. I'm not sure that would have been impossible, C# struct (value types) may implement interfaces, but this is not done here.

What you usually do is say that there is an Ordering available in implicit scope for your ID type, with ID : Ordering.

On a simple example:

import Ordering.Implicits._
def max[A : Ordering](x: A, y: A) : A = if (x > y) then x else y

This amounts to passing an Ordering (which is the same thing as a java.util.Comparator) to the function. Indeed, the declaration

def max[A : Ordering](x: A, y: A)

translates to

def max[A](x: A, y: A)(implicit ev: Ordering[A])

where ev is a fresh name. If A : Ordering appears on class rather than method definition, as in your code, it translates to an implicit parameter to the constructor, that will be kept in a field if needed, and be available in implicit scope in the class. This is more flexible than forcing A to be Comparable (Ordered in scala) as it may be used on a class that is not yours and has not implemented Comparable. You can choose between different Odering on the same class too, if only by reversing the default one: there is a def reverse : Ordering method on Ordering which does just that.

On the bad side, it is not likely the VM will be able to inline the call to the comparison method, but it was not likely either with an interface method in a generic.

Types which implement Comparable<T> in java automatically get an Ordering in implicit scope by virtue of an implicit method (ordered) in object Ordering. A java Comparator<T> can also be converted to an Ordering (Ordering.comparatorToOrdering).

importing Ordering.Implicits._ allows you the nice x > y syntax, when an Ordering[A] is in implicit scope.