In der Dokumentation der Clojure-Typ-Mechanismen heißt es, dass
- Konkrete Ableitung ist schlecht
- Sie können Datentypen nicht aus konkreten Klassen ableiten, sondern nur aus Schnittstellen
Einige der Kern-Clojure-Klassen verwenden jedoch eine konkrete Ableitung (dort sind andere Beispiele, aber das sind die einzigen Fälle, in denen die Oberklasse Teil von clojure.lang ) ist:
ARef erweitert AReference
Agent erweitert ARef
Atom erweitert ARef
Namespace erweitert AReference
Ref erweitert ARef
Var erweitert ARef
Zusätzlich gibt es viele abstrakte Klassen. Es gibt jedoch keine Möglichkeit, in Clojure das Äquivalent einer abstrakten Klasse zu erzeugen, und für mich scheint die Erweiterung einer abstrakten Klasse dieselben Nachteile aufzuweisen wie die regelmäßige konkrete Ableitung.
Warum wird hier konkret abgeleitet?
Ich fühle mich nicht autoritativ genug, wenn ich von den philosophischen Dingen spreche, aber hier sind meine zwei Cent.
Der Grund dafür, dass Ihr zitierter Text dort erscheint, besteht darin, bei Missbrauch von defrecord und deftype zu warnen. Clojure ermutigt nicht, Datensätze / Typen als API offenzulegen. Stattdessen sollte man die Schnittstelle wann immer möglich freilegen. Schließlich stellt OO-Sprache Klassen und FP-Sprache exponiert Funktionen / Methoden / Schnittstellen.
Auf der anderen Seite haben Sie erwähnt, dass clojures Implementierung selbst abstrakte Klassen verwendet und diese erbt. Ich würde diese eher als "die schmutzigen Arbeiten, die jemand zu tun hat" betrachten. JVM ist so konzipiert, dass es auf den Primitiven in der OO-Welt am effizientesten ist. Die Lücke zwischen OO World Virtual Machine und einer FP-World-Sprache muss von jemandem gefüllt werden.
Tags und Links inheritance clojure