This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-06
Channels
- # announcements (2)
- # architecture (2)
- # aws (18)
- # babashka (7)
- # beginners (149)
- # bristol-clojurians (4)
- # calva (11)
- # chlorine-clover (1)
- # cider (8)
- # clj-kondo (2)
- # cljdoc (2)
- # cljsrn (2)
- # clojure (186)
- # clojure-canada (3)
- # clojure-europe (3)
- # clojure-gamedev (5)
- # clojure-italy (1)
- # clojure-nl (13)
- # clojure-norway (4)
- # clojure-spec (25)
- # clojure-uk (32)
- # clojurescript (75)
- # core-async (2)
- # cursive (16)
- # data-science (3)
- # datomic (20)
- # docker (1)
- # emacs (26)
- # fulcro (7)
- # graphql (1)
- # incanter (1)
- # leiningen (1)
- # luminus (7)
- # malli (7)
- # mount (11)
- # off-topic (19)
- # pathom (15)
- # re-frame (9)
- # reagent (9)
- # remote-jobs (4)
- # ring-swagger (4)
- # shadow-cljs (63)
- # spacemacs (11)
- # sql (2)
- # vscode (7)
I was looking at an api that uses the newish java CompletableFuture stuff, and thinking what a bummer it would be to have to write all the adapter bits between that and core.async, then I realized you could (if you ignored all good practices about extending protocols you don't own to types you don't own) just extend core.async's protocols to the completeable future interfaces. https://gist.github.com/hiredman/1788aa052f26d127c00a1679656026f0
👍 4
It has been discussed recently in the Google group that this about protocols is just best practice, exceptions might be ok as long as unknowing users cannot run into your extensions conflicting with other library's