3 ms·
You have to use the java interop facilities if you want your own types to implement these abstractions though right? I recall some debate about changing this s
by mjw 14y ago
You have to use the java interop facilities if you want your own types to implement these abstractions though right?
I recall some debate about changing this so you can implement them using the native abstraction facilities in clojure (protocols), at which point I'd probably withdraw my point.
But yeah elegance is subjective. I use Clojure and broadly like it, JVM interop is really useful, but the lack of a crisp separation between clojure semantics and JVM semantics does still irk the purist in me a bit.
I guess I'd see Clojure and ClojureScript not as one language on two host platforms, but as one JVM language and another similar but not really source-compatible language on another platform which is influenced by it. Part of the philosophy seems to be to make pragmatic decisions which blur the boundary with the host platform, rather than try to abstract over the differences in APIs and runtime semantics.
- craigching 14y agoI'm still a clojure newb, but if I understand you correctly: >> I recall some debate about changing this so you can implement them using the native abstraction facilities in clojure (protocols) You mean records (defrecord): http://clojure.org/datatypes http://clojure.org/datatypes
- mjw 14y agoNot quite, I'm talking about replacing the various important java interfaces in clojure.lang (IFn, ISeq, IPersistentMap etc) with protocols, so you can implement them yourself without using any Java-specific language features. Dunno how feasible this is, but if a language is going to define its own abstraction features (here, protocols) on top of the underlying platform, it would seem cleaner to eat ones own dogfood in using these abstraction facilities for the core abstractions which the language and its core library are based on.