Dlaczego zmienne i niezmienne mapy listy mają różne porządki w Scali?

Question

Dlaczego niezmienna wersja magazynu ListMap zapisuje się w porządku rosnącym, a wersja zmienna przechowuje w porządku malejącym?

Oto test, który można użyć, jeśli masz scalatest-1.6.1.jar i JUnit-4.9.jar

@Test def StackoverflowQuestion() 
    { 
    val map = Map("A" -> 5, "B" -> 12, "C" -> 2, "D" -> 9, "E" -> 18) 
    val sortedIMMUTABLEMap = collection.immutable.ListMap[String, Int](map.toList.sortBy[Int](_._2): _*) 
    println("head : " + sortedIMMUTABLEMap.head._2) 
    println("last : " + sortedIMMUTABLEMap.last._2) 
    sortedIMMUTABLEMap.foreach(X => println(X)) 
    assert(sortedIMMUTABLEMap.head._2 < sortedIMMUTABLEMap.last._2) 

    val sortedMUTABLEMap = collection.mutable.ListMap[String, Int](map.toList.sortBy[Int](_._2): _*) 
    println("head : " + sortedMUTABLEMap.head._2) 
    println("last : " + sortedMUTABLEMap.last._2) 
    sortedMUTABLEMap.foreach(X => println(X)) 
    assert(sortedMUTABLEMap.head._2 > sortedMUTABLEMap.last._2) 
    } 

Herezje wyjście z testu Podania:

head : 2 
last : 18 
(C,2) 
(A,5) 
(D,9) 
(B,12) 
(E,18) 
head : 18 
last : 2 
(E,18) 
(B,12) 
(D,9) 
(A,5) 
(C,2) 

Answer 1

objawy mogą być uproszczone do:

scala> collection.mutable.ListMap(1 -> "one", 2 -> "two").foreach(println) 
(2,two) 
(1,one) 

scala> collection.immutable.ListMap(1 -> "one", 2 -> "two").foreach(println) 
(1,one) 
(2,two) 

w „sortowanie” w kodzie nie jest sedno problemu, połączenie do ListMap używa wywołania ListMap.apply z obiektu towarzyszącego, który tworzy mapę listy wspieraną zmienną lub niezmienną listą. Zasadą jest, że zamówienie reklamowe zostanie zachowane.

Różnica wygląda na to, że zmienna lista jest chroniona przez listę niezmienną , a wstawianie odbywa się z przodu. Dlatego właśnie podczas iteracji uzyskujesz zachowanie LIFO. Wciąż spoglądam na niezmienny, ale założę się, że wkładki są skutecznie z tyłu. Edycja, zmieniam zdanie: wstawienie jest prawdopodobnie z przodu, ale wygląda na to, że metoda immutable.ListMap.iterator postanawia odwrócić wynik z toList.reverseIterator na zwróconym iteratorze. Myślę, że warto go sprowadzić na listę mailingową.

Czy dokumentacja może być lepsza? Na pewno. Czy jest ból? Niezupełnie, nie pozwalam na to. Jeśli dokumentacja jest niekompletna, dobrze jest przetestować zachowanie lub sprawdzić źródło przed wybieraniem struktury w stosunku do innej.

W rzeczywistości może pojawić się ból, jeśli zespół Scala zdecyduje się zmienić zachowanie w późniejszym czasie i poczuje, że może, ponieważ zachowanie jest skutecznie nieudokumentowane i nie ma umowy.

---

Aby rozwiązać swój przypadek użycia wyjaśniono w komentarzu, powiedzmy zbierzesz liczbę częstotliwości ciąg w mapie (zmienny lub stały):

val map = Map("A" -> 5, "B" -> 12, "C" -> 2, "D" -> 9, "E" -> 18, "B" -> 5) 

Ponieważ trzeba tylko rozwiązać raz na koniec, można konwertować krotki z mapy do seq a następnie sortowania:

map.toSeq.sortBy(_._2) 
// Seq[(java.lang.String, Int)] = ArrayBuffer((C,2), (A,5), (B,5), (D,9), (E,18)) 

Answer 2

Jak widzę go ani ListMap roszczeń być sortowane map, tylko mapa zaimplementowane z Listą. W rzeczywistości nie widzę niczego w ich umowie, która mówi cokolwiek o zachowaniu zamówienia reklamowego.

Programowanie w Scali wyjaśnia, że ​​ListMap może być przydatna, jeśli wczesne elementy są bardziej dostępne, ale w przeciwnym razie ma niewielką przewagę nad Mapą.

Answer 3

Nie buduj żadnych oczekiwań na zamówienie, nie jest zadeklarowany i będzie się różnić między wersjami Scala.

Na przykład

import scala.collection.mutable.{ListMap => MutableListMap} 

MutableListMap("A" -> 5, "B" -> 12, "C" -> 2, "D" -> 9, "E" -> 18).foreach(println) 

na 2,9.1 zawiera: (E 18) (D, 9) (C-2) (B, 12) (A, 5)

ale 2.11.6 otrzymujemy: (E 18) (C, 2) (a, 5) (B 12) (D, 9)