Thanks to @jducoeur, I have a good example of how to write this function using Numeric[N], but I still don’t understand why it fails to work using B<:Ordering[B]
Can someone help me understand. I think the messages about String are a red herring. Right? Or is that real?
Is the problem that Ordering has no + and the compiler didn’t make it far enough to report that problem?
It’s a real error. Every value has a method +(String) added to it. Your du must not have a +(B) method, and w is not a String.
sorry, not understanding yet. w is of type B, right? and Some(du) is of type Option[B]. So is this saying that there exists at least one type which is Ordered but you cannot + two such objects?
You have B <: Ordering[B], which means that any instance of B implements an ordering on itself. Ordering does not have a method +.
I think what you want is an Ordering type class of B, Ordering[B], which you would pass as an implicit parameter. In that case, B wouldn’t need to be a subclass of anything in particular.
Note that B <: Ordering is almost never right. Ordering is a typeclass, which means that it is intended to be used as [B: Ordering], or an implicit parameter list of (implicit ordering: Ordering[B]). As opposed to Ordered, which is designed for inheritance, which uses the [B <: Ordered] syntax.
Yes, this is a common point of confusion, but they’re for the two different styles of Scala. Ordering is basically the FP approach, Ordered is the OO one. (This is specifically the example in the standard library that basically shows the two different ways to do the same things.)
Locations on a genome are ordered (chromosome plus position), but there is no obvious way to add two of them.
It doesn’t matter for the compiler, because Scala compiler is not a theorem prover. Compiler only cares about methods available on objects directly (i.e. through inheritance) or indirectly (i.e. through typeclasses).
Trait Numeric extends trait Ordering so you can depend only on Numeric and you’ll have both arithmetic and comparison operators.
@curoli, it’s good to have concrete examples like that to help understand how the pieces fit together. It’s not always obvious from the base rules, how they fit together.