This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-12
Channels
- # announcements (2)
- # bangalore-clj (4)
- # beginners (97)
- # calva (57)
- # cider (24)
- # clj-kondo (1)
- # cljdoc (4)
- # cljs-dev (8)
- # cljsrn (6)
- # clojure (27)
- # clojure-berlin (7)
- # clojure-dev (95)
- # clojure-europe (16)
- # clojure-italy (15)
- # clojure-losangeles (9)
- # clojure-nl (8)
- # clojure-spec (10)
- # clojure-uk (29)
- # clojurescript (25)
- # clojutre (2)
- # clr (6)
- # cursive (33)
- # datomic (20)
- # dirac (1)
- # duct (9)
- # fulcro (2)
- # graalvm (18)
- # jobs (5)
- # jobs-discuss (19)
- # nrepl (4)
- # nyc (1)
- # off-topic (18)
- # pathom (15)
- # re-frame (22)
- # reagent (4)
- # reitit (1)
- # rewrite-clj (9)
- # spacemacs (2)
- # xtdb (12)
@lee been trying to wrap my head around defprotocol+ - if you don't mind me asking, why do you think this is used over vanilla defprotocol in rewrite-clj? the original docs say: a protocol that won't evaluate if an equivalent protocol with the same name aleady exists. the version in rewrite-clj is a simpler version, right?
@sogaiu I remember asking myself the very same question and came to the foggy conclusion that it is just a performance optimization. I can’t tell you if it is still necessary but we could someday do perf tests with and without it to see what it gives us. For cljs it is currently a no-op.
i experimentally removed all of potemkin except defprotocol+ the other day when trying to get proto-rewrite-cljc to work with babashka the other day, so may be i can try without deprotocol+ too.
well rewrite-clj uses defprotocol+ as well. I’m guessing it might be the edn reader I am using that is causing graal problems, but that is just a wild guess.