Während Scala zu lernen, fand ich das Konzept implizit schwierig zu rationalisieren. Es erlaubt, Werte implizit zu übergeben, ohne sie explizit zu erwähnen.Was ist die primäre technische Herausforderung, die Scala implizit löst?
Was ist der Zweck des Seins und was ist das Problem, das es zu lösen versucht?
Es ist eine tiefe Frage wirklich Es ist etwas, das sehr mächtig ist und Sie können sie verwenden, um abstrakten Code zB typeclasses usw. zu schreiben, kann ich einige Tutorials empfehlen, die Sie sich ansehen können und dann vielleicht einen Chat haben können :) :) Es geht darum, vernünftige Standardwerte in Ihrem Code bereitzustellen. Auch die Magie des Aufrufs scheinbar nicht existierender Methoden auf Objekten, die einfach zu funktionieren scheinen! All diese guten Sachen werden über Implicits gemacht. Aber bei all seiner Macht kann es Leute dazu bringen, auch wirklich schlechten Code zu schreiben. Bitte schau dir Nick Partridges Präsentation hier an und ich bin mir sicher, wenn du mit ihm kommunizierst, wirst du verstehen, warum und wie man sich mit implicits befasst. Watch it here
Dick Walls excellent presentation with live coding Beide Teile beobachten.
warum die negative vote? Huh sowieso. –
Vermutung, dass der Downvote ist, weil Antworten nicht auf externe Ressourcen verweisen sollen, um eine Antwort zu liefern. Die Antwort sollte zusammenfassen. Auch Ihre Antwort unterstützt nicht, dass es sich um "vernünftige Vorgaben" als "die wichtigste technische Herausforderung" handelt. Liefern Standardargumente keine vernünftigen Standardwerte? –
hmm hatcha. Wird dann mehr Informationen aktualisieren. :) thx für die Antwort. –
Es gibt eine paper about type classes mit older slides und discussion.
Das implizite Übergeben eines Objekts, das eine Typklasse codiert, vereinfacht das Boilerplate.
Odersky reagierte nur auf einen critique of implicits dass
Scala wäre Scala nicht, wenn es nicht implizite Parameter und Klassen hat.
Das schlägt vor, dass sie eine Herausforderung lösen, die für das Design der Sprache von zentraler Bedeutung ist. Mit anderen Worten, unterstützende Klassen sind kein zusätzliches Anliegen.
Ein weiteres großartiges Feature dieses Papiers ist die Fußnote, die zeigt, welcher Zweig von Adriaan Moors 'Repository auschecken soll, damit die Beispiele unter "-Xexperimental" kompiliert werden. –
Ich kenne Typklassen und Haskell gut, aber ich sehe nicht die Verbindung zwischen impliziten und Typklassen. – Ana
@Ana: Dann sollten Sie das Papier lesen "[Klassen als Objekte und Impliziten] (https://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf)", die es ziemlich genau erklärt. Das Wesentliche ist: Sie wissen, wie GHC versteckte Methodenwörterbücher bei der Implementierung von Typklassen umgeht? Nun, der "Umgehungs" -Teil wird durch Implicits erreicht, und was ist ein "Method Dictionary" anders als ein Objekt? –
Im Kern ist implicit eine Möglichkeit, das Verhalten von Werten eines Typs auf eine lokale Ebene in Ihrem Programm und außerhalb des ursprünglichen Codes, der diese Werte definiert, zu steuern. Es ist ein Ansatz zur Lösung der expression problem.
Damit können Sie Ihre Kernkurse auf ihre grundlegendste Struktur und Verhalten konzentrieren und Verhalten auf höherer Ebene ausklammern. Es wird verwendet, um einen Ad-hoc-Polymorphismus zu erreichen, bei dem zwei formal nicht verwandte Datentypen nahtlos an dieselbe Schnittstelle angepasst werden können, so dass sie als Instanzen des gleichen Typs behandelt werden können.
Anstatt beispielsweise Ihre Datenmodellklassen mit JSON-Serialisierungsverhalten zu speichern, können Sie dieses Verhalten an anderer Stelle speichern und implizit ein Objekt mit der Fähigkeit zur Serialisierung erweitern. Dies führt zur Definition in einer implicit Instanz, die angibt, wie Ihr Objekt als "JSON-serialisierbar" und nicht als sein ursprünglicher Typ angezeigt werden kann, und ohne dass der reale Typ des Objekts bearbeitet wird.
Es gibt verschiedene Formen von implicit, die pretty thoroughly covered elsewhere sind. Zu den Anwendungsfällen gehören das "enhare-my-library" -Muster, das typeclass -Muster, implizite Konvertierungen und die Abhängigkeitsinjektion.
Was mich im Zusammenhang mit dieser Frage wirklich interessiert, ist, wie sich das von Ansätzen in anderen Sprachen unterscheidet.
Enhance-my-Bibliothek und typeclasses
In vielen anderen Sprachen, erreichen Sie dies durch Affen Patchen oder Erweiterungsmethoden (in der Regel, wo es keine Typprüfung ist). Diese Ansätze haben den Nachteil, unvorhersehbar zu komponieren und global anzuwenden. In statisch typisierten Sprachen ohne eine Möglichkeit, Klassen zu öffnen, müssen Sie normalerweise explizite Adapter erstellen. Dies hat den Nachteil einer Menge Standard. In statischen und dynamischen Sprachen können Sie vielleicht auch Reflektionen verwenden, aber normalerweise mit viel Zeremoniell und Komplexität.
In Haskell existieren Typklassen als ein erstklassiges Konzept. Sie sind jedoch global, sodass Sie nicht die lokale Kontrolle darüber erhalten, welche Typklasse in einer bestimmten Situation angewendet wird. In Scala steuern Sie über die importierten Module, welche Auswirkungen lokal im Bereich liegen. Und Sie können die implizite Auflösung immer ganz ausschließen, indem Sie Parameter explizit übergeben.
Menschen befürworten globale oder lokale Auflösung von Typklassen auf die eine oder andere Weise, je nachdem, wen Sie fragen.
Implizite Konvertierungen
Viele andere Sprachen haben keine Möglichkeit, dies zu erreichen. Aber es ist in Scala ziemlich verpönt geworden, vielleicht aus gutem Grund.
Sie mussten http://scalapuzzlers.com/ auf den Boden bringen. –
Holy Mir ist nicht klar, wie viele Rätsel es bei Scala gibt. – Ana
Diese Frage lässt viele schlechte Antworten zu, aber auch gute und prägnante. –