Perché `private val` e` private final val` sono diverse?

Lo pensavo private vale private final valsono la stessa cosa, finché non ho visto la sezione 4.1 in Scala Reference:

Una definizione di valore costante è della forma

final val x = e

dove e è un'espressione costante (§6.24). Il modificatore finale deve essere presente e non può essere fornita alcuna annotazione di tipo. I riferimenti al valore della costante x vengono trattati come espressioni costanti; nel codice generato sono sostituiti dal lato destro della definizione e.

E ho scritto un test:

class PrivateVal {
  private val privateVal = 0
  def testPrivateVal = privateVal
  private final val privateFinalVal = 1
  def testPrivateFinalVal = privateFinalVal
}

javap -c produzione:

Compiled from "PrivateVal.scala"
public class PrivateVal {
  public int testPrivateVal();
    Code:
       0: aload_0       
       1: invokespecial #19                 // Method privateVal:()I
       4: ireturn       

  public int testPrivateFinalVal();
    Code:
       0: iconst_1      
       1: ireturn       

  public PrivateVal();
    Code:
       0: aload_0       
       1: invokespecial #24                 // Method java/lang/Object."<init>":()V
       4: aload_0       
       5: iconst_0      
       6: putfield      #14                 // Field privateVal:I
       9: return
}

Il codice byte è proprio come dice Scala Reference: private valnon lo è private final val.

Perché lo scalac non tratta solo private valcome private final val? C'è una ragione di fondo?

Quindi, questa è solo una supposizione, ma era una seccatura perenne in Java che le variabili statiche finali con un letterale sul lato destro venissero integrate nel bytecode come costanti. Ciò genera sicuramente un vantaggio in termini di prestazioni, ma causa l'interruzione della compatibilità binaria della definizione se la "costante" cambia. Quando si definisce una variabile statica finale il cui valore potrebbe dover cambiare, i programmatori Java devono ricorrere ad hack come l'inizializzazione del valore con un metodo o un costruttore.

Un val in Scala è già definitivo in senso Java. Sembra che i progettisti di Scala stiano usando il modificatore ridondante final per indicare "il permesso di incorporare il valore costante". Quindi i programmatori Scala hanno il controllo completo su questo comportamento senza ricorrere ad hack: se vogliono una costante inline, un valore che non dovrebbe mai cambiare ma è veloce, scrivono "final val". se vogliono flessibilità per modificare il valore senza interrompere la compatibilità binaria, basta "val".

Penso che la confusione qui nasca dalla fusione dell'immutabilità con la semantica del finale. vals possono essere sovrascritti nelle classi figlie e quindi non possono essere trattati come final a meno che non siano contrassegnati come tali esplicitamente.

@Brian Il REPL fornisce l'ambito della classe a livello di linea. Vedere:

scala> $iw.getClass.getPackage
res0: Package = package $line3

scala> private val x = 5
<console>:5: error: value x cannot be accessed in object $iw
  lazy val $result = `x`

scala> private val x = 5; println(x);
5