Quando usare val o def nei tratti di Scala?

Stavo esaminando le diapositive in scala efficaci e nella diapositiva 10 si menziona di non usare mai valin una traitper i membri astratti e di usare definvece. La diapositiva non menziona in dettaglio perché l'uso di abstract valin a traitè un anti-pattern. Apprezzerei se qualcuno potesse spiegare le migliori pratiche sull'uso di val vs def in un tratto per metodi astratti

A defpuò essere implementato da a def, a val, a lazy valo an object. Quindi è la forma più astratta per definire un membro. Poiché i tratti sono solitamente interfacce astratte, dire che si desidera una valè dire come dovrebbe fare l'implementazione. Se chiedi a val, una classe di implementazione non può utilizzare a def.

A valè necessario solo se è necessario un identificatore stabile, ad esempio per un tipo dipendente dal percorso. È qualcosa di cui di solito non hai bisogno.

Confrontare:

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
  }
}

Se tu avessi

trait Foo { val bar: Int }

non saresti in grado di definire F1o F3.

Ok, e per confonderti e rispondere @ om-nom-nom, l'uso di vals astratte può causare problemi di inizializzazione:

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

object Fail extends Foo {
  val bar = 33
}

Fail.schoko  // zero!!

Questo è un brutto problema che a mio parere personale dovrebbe scomparire nelle future versioni di Scala riparandolo nel compilatore, ma sì, attualmente questo è anche un motivo per cui non si dovrebbero usare abstract vals.

Modifica (gennaio 2016): è consentito sostituire una valdichiarazione astratta con lazy valun'implementazione, in modo da evitare anche l'errore di inizializzazione.

Preferisco non usarlo valnei tratti perché la dichiarazione val ha un ordine di inizializzazione poco chiaro e non intuitivo. Puoi aggiungere un tratto alla gerarchia già funzionante e spezzerebbe tutte le cose che funzionavano prima, vedi il mio argomento: perché usare la semplice val in classi non finali

Dovresti tenere a mente tutte le cose sull'uso di queste dichiarazioni val che alla fine ti portano a un errore.

Aggiorna con un esempio più complicato

Ma ci sono momenti in cui non puoi evitare di usare val. Come menzionato da @ 0__, a volte è necessario un identificatore stabile edef non è uno.

Fornirei un esempio per mostrare di cosa stava parlando:

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
}

Questo codice produce l'errore:

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

Se ti prendi un minuto per pensare che capiresti che il compilatore ha un motivo per lamentarsi. Nel Access2.accesscaso in cui non potrebbe derivare il tipo di ritorno in alcun modo. def holdersignifica che potrebbe essere attuato in modo ampio. Potrebbe restituire diversi titolari per ogni chiamata e tali titolari incorporerebbero Innertipi diversi . Ma la macchina virtuale Java si aspetta che venga restituito lo stesso tipo.

Usare sempre def sembra un po 'imbarazzante poiché qualcosa del genere non funzionerà:

trait Entity { def id:Int}

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

Otterrai il seguente errore:

error: value id_= is not a member of Entity