This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-12
Channels
- # bangalore-clj (1)
- # beginners (28)
- # boot (33)
- # chestnut (3)
- # cider (35)
- # cljs-dev (64)
- # cljsrn (16)
- # clojure (95)
- # clojure-android (6)
- # clojure-austin (1)
- # clojure-italy (5)
- # clojure-korea (1)
- # clojure-russia (55)
- # clojure-sg (1)
- # clojure-spec (25)
- # clojure-uk (57)
- # clojurescript (120)
- # code-reviews (7)
- # community-development (2)
- # core-async (3)
- # cursive (6)
- # data-science (3)
- # datascript (10)
- # datomic (12)
- # devcards (1)
- # emacs (9)
- # gsoc (7)
- # hoplon (18)
- # lumo (2)
- # off-topic (10)
- # om (24)
- # onyx (17)
- # pedestal (46)
- # powderkeg (1)
- # protorepl (7)
- # re-frame (31)
- # ring-swagger (34)
- # spacemacs (10)
- # specter (9)
- # sql (39)
- # unrepl (9)
- # untangled (3)
- # utah-clojurians (1)
@rmuslimov perhaps structure it as a list of strings? That approach is simpler for the programmer, and easier to maintain
If my code accepts JS values at the boundary of the system, what’s the preferred way to use spec to validate it? AIUI, s/keys
only works with keywords. Is it common practice to convert all string keys to keyword keys when converting to CLJS in order to use spec? e.g. (js->clj input :keywordize-keys true)
@tbaldridge yes it is dead simple, however spec is longer that data it describes. I was wondering if I’m missing some nice shortcut macro for that
@rmuslimov no, I'm saying that this is the better approach:
(s/def ::email string?)
(s/def ::emails (s/coll-of ::email))
(s/def ::item (s/keys :req-un [::emails ::data]))
@tbaldridge it wasn’t real world example, I just created the most trivial example of the problem. Real world example would be something like:
(s/def ::original_currency ::currency-type)
(s/def ::currency ::currency-type)
(s/def ::original_total (s/and double? pos?))
(s/def ::original_taxes (s/and double? pos?))
(s/def ::taxes (s/and double? pos?))
(s/def ::total (s/and double? pos?))
(s/def ::original_total (s/and double? pos?))
(s/def ::rate (s/keys :req-un [::rate_key ::original_currency ::currency ::original_total
::original_taxes ::taxes ::total ::original_total]))
ah, I see
so, I thought why not something like:
(s/def
::rate {::taxes ::money
::original_taxes ::money
::total ::money
::original_total ::money
...etc})
@gfredericks Thinking more about defn+spec made me explore why i wanted it and alternative ways to get the the same result.
One key thing spec gives me is protection from "garbage in garbage out" errors while I'm hacking up new features. Colocating the spec with the defn is helpful during this phase because I'm refactoring heavily as I go - if the s/fdef specs were in another file they're more likely to get stale.
I can do this by adding s/assert statements in my defn.
Later when code stabilises I see the logic of specs living in a different namespace so they are out of the way but still available to reference.
As an aside, IDE support to allow hiding of spec statements would make that less important. #cursive
But I appreciate the idea that separate namespaces for specs also allow for different specs to be applied to the same code depending on need.
@gfredericks defn+spec would benefit from the s/assert flag so that it can have no impact on prod performance.
@rmuslimov that's covered in some of the spec docs
I did actually, as far as I can see: only s/keys
is given for building spec for maps. I cannot do something close to way I proposed. Developer should always define explicitly keys like (s/def ::total ::money)
and then build spec for map with s/keys
.
It's quite intentional that information maps are built as sets of attributes. This is a key design principle in spec - the semantics belong to the attribute, not to the map.
This is covered a bit in https://clojure.org/about/spec
is there any context-independent benefit/downside of defining intermediate predicate fn over inline spec definition?
(defn nsless-keyword? [k]
(and (keyword? k) (nil? (namespace k))))
(defn ::nsless-keyword nsless-keyword?)
vs:
(defn ::nsless-keyword (s/and keyword? (complement namespace)))
Well it affects automatic generator capability
But you should really use simple-keyword? rather than either of those
Which has a built in generator
I would like to be able to attach a docstring to a spec. Has there been an progress on https://dev.clojure.org/jira/browse/CLJ-1965?