StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Currently, what you are using is the <code>scala.collection.SortedMap</code> trait, whose <code>++</code> method is inherited from the <code>MapLike</code> trait. Therefore, you see the following behaviour:</p> <pre><code>scala> import scala.collection.SortedMap import scala.collection.SortedMap scala> val a = SortedMap(1->2, 3->4) a: scala.collection.SortedMap[Int,Int] = Map(1 -> 2, 3 -> 4) scala> val b = SortedMap(2->3, 4->5) b: scala.collection.SortedMap[Int,Int] = Map(2 -> 3, 4 -> 5) scala> a ++ b res0: scala.collection.Map[Int,Int] = Map(1 -> 2, 2 -> 3, 3 -> 4, 4 -> 5) scala> b ++ a res1: scala.collection.Map[Int,Int] = Map(1 -> 2, 2 -> 3, 3 -> 4, 4 -> 5) </code></pre> <p>The type of the return result of <code>++</code> is a <code>Map[Int, Int]</code>, because this would be the only type it makes sense the <code>++</code> method of a <code>MapLike</code> object to return. It seems that <code>++</code> keeps the sorted property of the <code>SortedMap</code>, which I guess it is because <code>++</code> uses abstract methods to do the concatenation, and those abstract methods are defined as to keep the order of the map.</p> <p>To have the union of two sorted maps, I suggest you use <code>scala.collection.immutable.SortedMap</code>.</p> <pre><code>scala> import scala.collection.immutable.SortedMap import scala.collection.immutable.SortedMap scala> val a = SortedMap(1->2, 3->4) a: scala.collection.immutable.SortedMap[Int,Int] = Map(1 -> 2, 3 -> 4) scala> val b = SortedMap(2->3, 4->5) b: scala.collection.immutable.SortedMap[Int,Int] = Map(2 -> 3, 4 -> 5) scala> a ++ b res2: scala.collection.immutable.SortedMap[Int,Int] = Map(1 -> 2, 2 -> 3, 3 -> 4, 4 -> 5) scala> b ++ a res3: scala.collection.immutable.SortedMap[Int,Int] = Map(1 -> 2, 2 -> 3, 3 -> 4, 4 -> 5) </code></pre> <p>This implementation of the <code>SortedMap</code> trait declares a <code>++</code> method which returns a <code>SortedMap</code>.</p> <p>Now a couple of answers to your questions about the type bounds:</p> <ul> <li><p><code>Ordered[T]</code> is a trait which if mixed in a class it specifies that that class can be compared using <code><</code>, <code>></code>, <code>=</code>, <code>>=</code>, <code><=</code>. You just have to define the abstract method <code>compare(that: T)</code> which returns <code>-1</code> for <code>this < that</code>, <code>1</code> for <code>this > that</code> and <code>0</code> for <code>this == that</code>. Then all other methods are implemented in the trait based on the result of <code>compare</code>.</p></li> <li><p><code>T <% U</code> represents a view bound in Scala. This means that type <code>T</code> is either a subtype of <code>U</code> or it can be implicitly converted to <code>U</code> by an implicit conversion in scope. The code works if you put <code><%</code> but not with <code><:</code> as <code>X</code> is not a subtype of <code>Ordered[X]</code> but can be implicitly converted to <code>Ordered[X]</code> using the <code>OrderedX</code> implicit conversion.</p></li> </ul> <p><strong>Edit:</strong> Regarding your comment. If you are using the <code>scala.collection.immutable.SortedMap</code>, you are still programming to an interface not to an implementation, as the immutable <code>SortedMap</code> is defined as a <code>trait</code>. You can view it as a more specialised trait of <code>scala.collection.SortedMap</code>, which provides additional operations (like the <code>++</code> which returns a <code>SortedMap</code>) and the property of being immutable. This is in line with the Scala philosophy - prefer immutability - therefore I don't see any problem of using the immutable <code>SortedMap</code>. In this case you can guarantee the fact that the result will <em>definitely</em> be sorted, and this can't be changed as the collection is immutable.</p> <p>Though, I still find it strange that the <code>scala.collection.SortedMap</code> does not provide a <code>++</code> method witch returns a <code>SortedMap</code> as a result. All the limited testing I have done seem to suggest that the result of a concatenation of two <code>scala.collection.SortedMap</code>s indeed produces a map which keeps the sorted property. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload