2014-06-30 38 views
7

W źródle Scala, znalazłem:Dlaczego `zerowe jest zdefiniowany jako` przypadku object`

case object Nil extends List[Nothing] { 
    ... 
} 

Nie mogę zrozumieć, dlaczego to jest zadeklarowana jako case object zamiast object?

Znalazłem to pytanie [Difference between case object and object] jest przydatna, i myślę, że z tego powodu jest kluczem:

domyślne implementacje serializacji

ponieważ często wysyłają listy danych do innego uczestnika, więc Nil musi być możliwy do serializacji, prawda?


pomocą dostarczonych odpowiedzi (dzięki), staram się napisać kod, aby go zweryfikować:

trait MyList[+T] 

object MyNil extends MyList[Nothing] 

val list: MyList[String] = MyNil 

list match { 
    case MyNil => println("### is nil") 
    case _ => println("### other list") 
} 

Widać MyNil nie jest case object, ale nadal można go używać w dopasowywanie wzorca. Tutaj jest wyjście:

### is nil 

Czy źle rozumiem coś?

Odpowiedz

2

Jak wspomniano w komentarzach tego połączonego pytanie, jedno masz jest ładniejsza .toString wynik

scala> MyNil.toString 
res0: String = [email protected] 

scala> case object MyNil2 extends MyList[Nothing] 
defined module MyNil2 

scala> MyNil2.toString 
res2: String = MyNil2 

scala> Nil.toString 
res1: String = List() 
5

Ogólnie danych niezmiennych, pytanie nie powinno być „dlaczego jest to sprawa przedmiot (lub klasa) "ale raczej" Czy mogę uczynić z tego obiekt sprawy? ". Z kilkoma małymi wyjątkami (głównie z powodu dziedziczenia), elementy danych w Scali powinny być niezmienne i powinny być implementowane za pomocą klas/obiektów case. Biorąc pod uwagę, że wdrażanie Nil i :: jako obiektu sprawy i klasy sprawy (odpowiednio) jest zwyczajną praktyką, dla której nie ma wad.