10

In the documentation of Clojure's type mechanisms, it is stated that

  • Concrete derivation is bad
    • you cannot derive datatypes from concrete classes, only interfaces

However, some of the core Clojure classes use concrete derivation (there are other examples, but these are the only cases in which the superclass is part of clojure.lang):

  • ARef extends AReference
  • Agent extends ARef
  • Atom extends ARef
  • Namespace extends AReference
  • Ref extends ARef
  • Var extends ARef

In addition, there are many abstract classes. However, there is no way to create the equivalent of an abstract class in Clojure, and to me, extension of an abstract class seems to have all the same drawbacks as regular concrete derivation.

Why is concrete derivation used here?

Sam Estep
  • 12,974
  • 2
  • 37
  • 75
  • The same page also warns against mutability and encapsulation, yet classes in `clojure.lang` contain plenty of mutable private fields. Don't confuse the internal implementation details of the language with how it's intended to be used. – Alex Nov 18 '15 at 13:33
  • 1
    @Alex The only reason I care is that extension of the interfaces in `clojure.lang` is the *only* way to implement new data structures in Clojure that are compatible with the functions in `clojure.core`. If everything in that package is truly just implementation details, then knowledge of its workings should not be required for such extension. – Sam Estep Nov 18 '15 at 13:38

1 Answers1

3

I don't feel myself authoritative enough when speaking of the philosophy stuff, but here are my two cents.

The reason your quoted text appears there, is to warn on abuse of defrecord and deftype. Clojure does not encourage exposing records/types as API. Instead, one should expose interface whenever possible. After all, OO-language exposes classes and FP-language exposes functions/methods/interfaces.

On the other hand, you mentioned clojure's implementation itself uses abstract classes and inherits them. I would rather consider those as "the dirty works that some one has to do". JVM is designed such that it's most efficient on the primitives in the OO world. The gap between OO world virtual machine and a FP-world language has to be filled by somebody.

Davyzhu
  • 1,109
  • 9
  • 17
  • That makes sense, but I'd need to see more support for your argument to believe that the use of abstract classes here is simply a "necessary evil" and, without the performance characteristics of the JVM, would be inferior to the use of pure interfaces. It just seems like Rich Hickey has a very deliberate reason here. – Sam Estep Nov 18 '15 at 12:18