This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-18
Channels
- # aleph (12)
- # beginners (31)
- # boot (67)
- # cider (17)
- # cljs-dev (14)
- # clojure (111)
- # clojure-dev (1)
- # clojure-france (4)
- # clojure-gamedev (1)
- # clojure-italy (49)
- # clojure-nl (3)
- # clojure-poland (2)
- # clojure-russia (18)
- # clojure-spec (15)
- # clojure-uk (68)
- # clojurescript (33)
- # core-typed (1)
- # datomic (15)
- # emacs (3)
- # graphql (4)
- # hoplon (36)
- # leiningen (3)
- # lumo (44)
- # mount (2)
- # off-topic (46)
- # om (21)
- # onyx (47)
- # parinfer (22)
- # pedestal (21)
- # protorepl (4)
- # quil (4)
- # re-frame (15)
- # reagent (4)
- # ring-swagger (9)
- # rum (27)
- # spacemacs (11)
- # vim (7)
- # yada (8)
@lvh I've heard from Cognitect team members that they use spec for the pure side of things, and not IO-bits and bobs. I suppose in this case that would mean specifying what happens inside the deferred operation and not the delayed (maybe IO?) side of things. I think https://clojure.org/guides/spec#_combining_code_check_code_and_code_instrument_code may be a good example of how to split the specification and deferred/side of things?
@lvh that makes sense. I've struggled with specifying Datomic in the past and ended up only annotating the pure transaction building bits etc.
wait; are they hard because they’re impure, or hard because some things are wrapped in a deferred
I thought it was strictly the latter; it may be wrapped in a deferred but I still have Strong Opinions(TM) about what the value inside that deferred will get to look like
@lvh I don't know about things being hard, but if you're dealing with executors and thread pools specs may not be appropriate?
the stubbing affects the var itself so executors and thread pools get sidestepped entirely
of course, that enables plenty of cases where e.g. you’d have a livelock in prod that doesnt’ show up in testing