This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-18
Channels
- # bangalore-clj (1)
- # beginners (36)
- # boot (119)
- # braid-chat (16)
- # cider (14)
- # cljs-dev (34)
- # cljsrn (7)
- # clojars (9)
- # clojure (91)
- # clojure-austin (1)
- # clojure-bangladesh (1)
- # clojure-dusseldorf (5)
- # clojure-israel (1)
- # clojure-russia (3)
- # clojure-spec (6)
- # clojure-uk (7)
- # clojurescript (11)
- # community-development (1)
- # core-async (5)
- # cursive (6)
- # datomic (11)
- # dirac (12)
- # funcool (24)
- # leiningen (5)
- # luminus (5)
- # off-topic (2)
- # om (69)
- # om-next (16)
- # overtone (4)
- # perun (19)
- # re-frame (23)
- # reagent (38)
- # specter (7)
- # uncomplicate (9)
- # yada (4)
Any thoughts on the namespaced keywords in Datomic vs the ones we need for clojure.spec? I don't want to put fully qualified namespaces into my data model, since data lives longer than code.
can you expand on what you mean by fqns, @magnars?
you mean e.g. :org.your-company.your-app.your-module/thing
vs simply :module/thing
?
yes. As far I understand, spec encourages the former, since you can then use the ::
- but I guess that it is entirely optional since the spec registry is global.
yeah. so we have to deal with this at some point too, when we start using spec
:: syntax is really nice, but, of course, you can also just not use it for those things you're specing that will live in Datomic
that is, i'd just (s/def :module/thing some-spec)
yeah, that makes sense. I was initially under the impression that the fqns were significant (that clojure would look up the spec def in that ns), so that contributed to my confusion.
naw, it's in an atom i believe