Beim Nachdenken über den Code Predef.scala habe ich folgendes bemerkt:
Weißt du überhaupt, warum dieses Stück scheinbar nutzlosen Code existiert?
Letztendlich kommt es auf die Art Löschung (die sowohl Java als auch Scala verwenden) .
Stellen Sie sich diesen Code vor:
%Vor%Alles ist gut hier. Was aber, wenn wir die Parameter von einzelnen Werten in eine Sequenz ändern?
%Vor%Jetzt haben wir einen Fehler:
%Vor%Und sehen Sie die Nachricht "Habe denselben Typ nach dem Löschen" - das ist unser Hinweis.
Warum ist die Sequenz fehlgeschlagen?
Da die JVM keine Generics unterstützt, bedeutet dies, dass Ihre stark typisierten Auflistungen (wie die Sequenz von Ints oder Strings) dies wirklich nicht sind. Sie werden in Container von Object kompiliert, da dies von der JVM erwartet wird. Die Typen sind "gelöscht".
Nach dem Kompilieren sehen alle so aus (wir werden gleich sehen, was sie sind):
%Vor%Offensichtlich ist das nicht beabsichtigt.
Wie geht Java damit um?
Erzeugt hinter den Kulissen Bridge-Methoden . Magie!
Scala macht diese Magie nicht (obwohl es diskutiert ) - stattdessen verwendet es Dummy-Implicits.
Lass uns unsere Definition ändern
%Vor%Und jetzt kompiliert es! Aber ... warum?
Schauen wir uns den Code an, den scalac generiert hat (scalac-print foo.scala)
%Vor%OK - wir haben also drei verschiedene foo-Methoden, die sich nur durch ihre impliziten Parameter unterscheiden.
Und jetzt nennen wir sie:
%Vor%Und wie sieht das aus (ich entferne hier eine Menge anderen Code ...)
%Vor%Jeder Anruf erhielt also den impliziten Parameter, der für die korrekte Entschlüsselung des Anrufs erforderlich ist.
Warum existiert DummyImplicit? Um sicherzustellen, dass es einen Typ gibt, für den es immer einen impliziten Wert geben wird (andernfalls müssten Sie sicherstellen, dass er verfügbar ist).
In der Dokumentation steht "Ein Typ, für den es immer einen impliziten Wert gibt". - Also existiert der implizite Wert immer, um in solchen Fällen verwendet zu werden.
Tags und Links scala