Fork me on GitHub
#clojure-dev
<
2016-10-26
>
mpenet10:10:42

Any chance we might get http://dev.clojure.org/jira/browse/CLJ-1255 resolved, or maybe guidance on how to provide a patch for it maybe?

alexmiller11: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.

mpenet11:10:22

ok, thanks for the info

bronsa12:10:59

i wrote a prototype of that a while ago at https://github.com/bronsa/clojure/tree/defclass/ if you're interested

mpenet12:10:07

bookmarked thanks

cfleming18:10:17

@mpenet Here’s the design doc for that branch: https://docs.google.com/document/d/1OcewjSpxmeFRQ3TizcaRRwlV34T8wl4wVED138FHFFE/edit?usp=sharing. I have it at https://github.com/cursive-ide/clojure/tree/defclass too. I have it rebased onto Clojure 1.8 locally but haven’t tested or pushed that yet.

cfleming18:10:04

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

alexmiller18: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

alexmiller18:10:37

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

alexmiller18: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

mpenet19:10:04

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

mpenet19:10:50

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

cfleming23:10:27

Right, extending abstract classes is idiomatic in Java frameworks.