With reference to the tutorial:
https://hello-scala.com/240-collections-maps.html
Please locate:
"Note that the last example probably only makes sense for a sorted Map."
"the last example" in the above statement:
val sortedMap = Map(
1 -> "a",
2 -> "b",
3 -> "c",
4 -> "d"
)
sortedMap.take(2) // Map(1 -> a, 2 -> b)
According to the above statement, Map.take(2) makes sense only when the Map is sorted.
val unSortedMap = Map(
2 -> "b",
1 -> "a",
4 -> "d",
3 -> "c"
)
unSortedMap.take(2) // Map(2 -> b, 1 -> a)
Question 1: Doesn't unSortedMap.take(2) make sense?
Question 2: If the answer to Q1 is no, why?
The comment is referring to the literal
SortedMapclass. In aSortedMap, the entries are sorted by their keys. ASortedMapinitialized with your data will always have the orderSortedMap(1 -> "a", 2 -> "b", 3 -> "c", 4 -> "d"), because that's the only way for the keys to be sorted. For a plainMap, the order is not guaranteed. In particular, forSortedMap,takerespects==: ifxs == ysthenxs.take(n) == ys.take(n). But forMap, your example shows that's not true. Since aMapis "supposed" to be an unordered collection of mappings, you're not supposed to depend on its "order". Notice that if you extend your maps to 6 elements, their order completely changes, because of implementation details of the library. It only makes sense to usetakeon a genericMapif you truly don't care which mappings you get out. E.g. it would be acceptable if you were "splitting" the map so you could operate on its pieces in parallel, or if you're "chunking" it so you can serialize it, but you can't usetakefor "logical" operations, like adding a bunch of mappings to aMapand expecting them to come back out in the order you put them in.