Kiedy używać val lub def w cechach Scala?

Przeglądałem efektywne slajdy scala i na slajdzie 10 wspomina się, że nigdy nie używaj valich traitjako abstrakcyjnych członków i używaj defzamiast tego. Slajd nie wspomina szczegółowo, dlaczego użycie abstrakcji valw a traitjest anty-wzorcem. Byłbym wdzięczny, gdyby ktoś mógł wyjaśnić najlepsze praktyki dotyczące używania wartości val vs def w cechach metod abstrakcyjnych

A defmożna zaimplementować za pomocą a def, a val, a lazy vallub an object. Jest to więc najbardziej abstrakcyjna forma definiowania członka. Ponieważ cechy są zwykle abstrakcyjnymi interfejsami, stwierdzenie, że chcesz, valto powiedzenie, jak powinna działać implementacja. Jeśli poprosisz o a val, klasa implementująca nie może użyć def.

A valjest potrzebne tylko wtedy, gdy potrzebujesz stabilnego identyfikatora, np. Dla typu zależnego od ścieżki. To jest coś, czego zwykle nie potrzebujesz.

Porównać:

trait Foo { def bar: Int }

object F1 extends Foo { def bar = util.Random.nextInt(33) } // ok

class F2(val bar: Int) extends Foo // ok

object F3 extends Foo {
  lazy val bar = { // ok
    Thread.sleep(5000)  // really heavy number crunching
    42
  }
}

Gdybyś miał

trait Foo { val bar: Int }

nie byłbyś w stanie zdefiniować F1lub F3.

OK, i żeby zmylić Cię i odpowiedzieć @ om-nom-nom - użycie abstrakcyjnych vals może powodować problemy z inicjalizacją:

trait Foo { 
  val bar: Int 
  val schoko = bar + bar
}

object Fail extends Foo {
  val bar = 33
}

Fail.schoko  // zero!!

Jest to brzydki problem, który moim zdaniem powinien zniknąć w przyszłych wersjach Scali poprzez naprawienie go w kompilatorze, ale tak, obecnie jest to również powód, dla którego nie należy używać abstrakcyjnych vals.

Edycja (styczeń 2016 r.): Możesz zastąpić abstrakcyjną valdeklarację lazy valimplementacją, aby również zapobiec niepowodzeniu inicjalizacji.

Wolę nie używać valw cechach, ponieważ deklaracja val ma niejasną i nieintuicyjną kolejność inicjalizacji. Możesz dodać cechę do już działającej hierarchii, a to zepsułoby wszystkie rzeczy, które działały wcześniej, zobacz mój temat: dlaczego używać zwykłego val na zajęciach niedokończonych

Powinieneś mieć na uwadze wszystkie rzeczy związane z używaniem tych deklaracji val, które ostatecznie prowadzą do błędu.

Zaktualizuj za pomocą bardziej skomplikowanego przykładu

Ale są chwile, kiedy nie można było uniknąć używania val. Jak wspomniał @ 0__, czasami potrzebujesz stabilnego identyfikatora, a nim defnie jest.

Podałbym przykład, aby pokazać, o czym mówił:

trait Holder {
  type Inner
  val init : Inner
}
class Access(val holder : Holder) {
  val access : holder.Inner =
    holder.init
}
trait Access2 {
  def holder : Holder
  def access : holder.Inner =
    holder.init
}

Ten kod powoduje błąd:

 StableIdentifier.scala:14: error: stable identifier required, but Access2.this.holder found.
    def access : holder.Inner =

Jeśli zastanowisz się przez chwilę, zrozumiesz, że kompilator ma powód do narzekania. W Access2.accessprzypadku, gdy nie może w żaden sposób wyprowadzić typu zwracanego. def holderoznacza, że ​​można by go wdrożyć na szeroką skalę. Mógłby zwrócić różnych posiadaczy dla każdego połączenia, a posiadacze mogliby zawierać różne Innertypy. Ale maszyna wirtualna Java oczekuje zwrócenia tego samego typu.

Zawsze używanie def wydaje się trochę niezręczne, ponieważ coś takiego nie zadziała:

trait Entity { def id:Int}

object Table { 
  def create(e:Entity) = {e.id = 1 }  
}

Otrzymasz następujący błąd:

error: value id_= is not a member of Entity