Uso del modificatore finale privato di Scala?

Question

Per che cosa posso usare il modificatore private final in Scala per?

dato il codice qui sotto:

1| class A { def callFoo = foo; private final def foo = "bar of A" } 
2| class B extends A { private final def foo = "bar of B"} 
3| println((new A()).callFoo) 
4| println((new B()).callFoo) 

Linea 3 e 4 stampe:

1| bar of A 
2| bar of A 

E 'comprensibile il motivo per cui la linea 2 non stampa bar of B perché ci sono in realtà due foo definizioni e questi ultimi in B non sovrascrive il primo in A. Altrimenti Scala richiederebbe il override - invece del modificatore final.

Quindi perché Scala non ha semplicemente vietato la combinazione dei modificatori private final?

Answer 1

Ok, questo è difficile. La tua domanda: "Allora perché Scala non ha semplicemente vietato la combinazione dei modificatori finali privati?" si basa sul presupposto che questa combinazione non ha utilità.

Diciamo che hai ragione (e lo sei, ad eccezione di un piccolo dettaglio, che verrà citato in seguito). Non sono un compilatore, ma dal mio punto di vista "semplicemente proibito" non è probabilmente così semplice (almeno in questo caso). E perché qualcuno dovrebbe tentare di farlo? Quali sono i trade-off? Solo perché qualcosa non è utile non significa necessariamente che faccia del male. Basta non usarlo ...

Ora ecco il piccolo dettaglio che sembra aver trascurato. Il modificatore private è un modificatore di visibilità, il che significa che class B non è a conoscenza dell'esistenza. Ma i modificatori di visibilità di Scala sono un po 'più complessi di quelli di Java. Supponiamo che per qualsiasi ragione tu richieda il codice mostrato nel seguente frammento di codice, il compilatore non lo consentirà.

package scope 

class A { 
    def callFoo = foo; 
    private[scope] final def foo = "bar of A" 
} 
class B extends A { 
    private[scope] final def foo = "bar of B" 
} 

object Main extends App { 
    println((new A()).callFoo) 
    println((new B()).callFoo) 
} 

Questo è uno degli errori forniti dal compilatore: "metodo foo non può prevalere membro finale".

Quindi ecco qui. Scala vieta semplicemente questa combinazione;)

Answer 2

inizialmente ho pensato che era quello di evitare metodi privati ​​imperativi di classi nidificate, ma a quanto pare non:

class A { 
    private final def foo = 0 

    class B extends A { 
    override def foo = 1 
    } 
} 

error: method foo overrides nothing 
      override def foo = 1 
         ^

Forse è solo per semplificare il refactoring? Quindi, se hai un metodo final, prova a renderlo private, e scopri che non è necessario che sia private dopotutto, non perderai final ity nel processo?

Answer 3

Affrontare la questione più ampia,

Allora perché Scala non semplicemente proibiscono la combinazione dei modificatori finali privato?

Questa è una nuova regola e, a questo, una nuova eccezione. Rende la lingua più complessa e assolutamente senza alcun guadagno. Perché rendere le cose più complicate senza una buona ragione?

Questo è il genere di cose che Java fa a cui Odersky non piace molto.Perché la lingua diventi più complessa, ci deve essere qualche guadagno.