Warum Scala doppelten Konstruktor benötigt? (java.lang.NoSuchMethodException)

Question

Ich habe diesen Fehler in meinem Hadoop-Job erhalten.
java.lang.NoSuchMethodException: <PackageName>.<ClassName>.<init>(<parameters>) In den meisten Scala-Code, würden Sie es in der Kompilierzeit haben. Aber da dieser Job in Runtime aufgerufen wird, habe ich ihn in der Kompilierzeit nicht abgefangen.

Ich würde denken, Standardparameter würde Konstruktoren mit beiden Signaturen verursachen, erstellt werden, wobei ein einzelnes Argument.

class BasicDynamicBlocker(args: Args, evaluation: Boolean = false) extends Job(args) with HiveAccess { 
//I NEEDED THIS TOO: 
def this(args: Args) = { 
    this(args, false) 
} 

... }

habe ich gelernt, auf die harte Weise, dass ich mit this den überladenen Konstruktor zu erklären brauchte. (Ich wollte dies schreiben, falls es jemand anderem hilft.) Ich habe auch eine kleine Frage. Es erscheint mir immer noch überflüssig. Gibt es einen Grund, warum die Design-Einschränkungen der Scala-Sprache dies erfordern?

Answer 1

Es ist nicht wie beim Standard-Parametern haben Sie Überlastungen für jeden möglichen Fall erzeugt erhalten, wie zum Beispiel:

def method(num: Int = 4, str: String = "") = ??? 

Sie Compiler

def method(num: Int) = method(num, "") 
def method(str: String) = method(4, str) 
def method() = method(4, "") 

aber das ist nicht zu generieren erwarten der Fall.

Sie werden stattdessen Methoden erstellt (in Begleitobjekt) für jeden Standard-param

def method$default$1: Int = 4 
def method$default$2: String = "a" 

und wann immer Sie in Ihrem Code sagen

method(str = "a") 

wird es nur zu

geändert werden

method(method$default$1, "a") 

Also in Ihrem Fall hat Konstruktor mit Signatur this(args: Args) gerade getan nicht vorhanden, es gab nur die 2-Param-Version.

können Sie mehr hier lesen: http://docs.scala-lang.org/sips/completed/named-and-default-arguments.html