Scala generics: Int not conforming to Comparable?
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 exten开发者_开发问答ds BaseWithID[TestBase,TestMeta,Int]
trait TestMeta extends Meta[TestBase,TestMeta,Int]
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.
The answer to "Does that mean that Int is not Comparable in Scala?" is obviously YES, because if I replace Int with java.lang.Integer, then it compiles without error. The problem is then, that I end up having to create a wrapper object every time that I access the ID, which is going to happen often and therefore be expensive.
I wanted to specify that ID is Comparable/Ordered so that I could make the BaseWithID itself ordered, and define the compare method explicitly in it by using the comparable IDs.
The solution, at the moment, seems to be to not specify that ID is ordered, and let the concrete class implement compare itself, instead of implementing it a single time in the trait. Has anyone got a better solution?
精彩评论