Fork me on GitHub

Any chance we might get resolved, or maybe guidance on how to provide a patch for it maybe?

Alex Miller (Clojure team)11:10:39

my comment there is from my discussions with Rich about it - he’s open to something under those guidelines. so that is the guidance. it’s far from the top of my list but if someone wants to work on it, go for it.


ok, thanks for the info


i wrote a prototype of that a while ago at if you're interested


bookmarked thanks


@mpenet Here’s the design doc for that branch: I have it at too. I have it rebased onto Clojure 1.8 locally but haven’t tested or pushed that yet.


It passed all the Clojure unit tests, so I’ll push it when I get a minute.

Alex Miller (Clojure team)18:10:16

I think Rich would find something like this persuasive and he’s said he’s open to it, with the caveats I listed in the ticket and which seem to be covered in the doc

Alex Miller (Clojure team)18:10:37

that said, “open to it” does not mean “will accept it” :)

Alex Miller (Clojure team)18:10:59

I think his main concern is that his belief is that concrete inheritance is no good and Clojure has no desire to do anything that makes that easier or possible with respect to Clojure types. But that it is convenient for the purposes of interop to do this occasionally for Java types


Makes sense. I strictly need this for interop here. It's quite common in java libs to require this.


The doc does a great job at explaining the why/how I think


Right, extending abstract classes is idiomatic in Java frameworks.