This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-10
Channels
- # beginners (151)
- # cider (41)
- # cljdoc (7)
- # cljs-dev (6)
- # clojure (92)
- # clojure-dev (5)
- # clojure-italy (26)
- # clojure-losangeles (1)
- # clojure-nl (10)
- # clojure-russia (3)
- # clojure-spec (23)
- # clojure-uk (82)
- # clojurescript (56)
- # clojutre (1)
- # core-async (3)
- # cursive (15)
- # datomic (26)
- # editors (3)
- # emacs (3)
- # events (2)
- # figwheel-main (192)
- # fulcro (66)
- # leiningen (12)
- # mount (1)
- # off-topic (131)
- # portkey (6)
- # re-frame (38)
- # reagent (10)
- # reitit (7)
- # ring-swagger (55)
- # shadow-cljs (21)
- # spacemacs (11)
- # tools-deps (48)
maybe a wiki page somewhere cataloging the regular var linkage case vs. all the exceptions to var linkage would be a good useful
I may be about 1/3 of the way there...
Will send out a link if I get something for people to critique
OK, I have used the nodisassemble library to look at the JVM bytecode of a normal Clojure function call that derefs through a Var, and compared that to a defprotocol method call. The Clojure compiler recognizes that when the Var in function position of a call like (a-var-name ...)
is a protocol method, it emits different byte code that is roughly: "if the first arg implements the Java interface created when defprotocol was done, do invokeinterface on that Java interface, without regard to the value of the Clojure Var. Otherwise, do a normal Clojure function call that indirects through the current value of the Clojure Var created for the protocol method." There is a 1-item cache that is actually checked before seeing if the arg implements the Java interface, that skips the first if, too.
In short, from the JVM byte code, it makes sense that some but not all protocol method calls ignore the value of the protocol method Vars.