This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-26
Channels
- # aleph (2)
- # aws-lambda (18)
- # beginners (81)
- # boot (3)
- # cider (25)
- # cljs-dev (274)
- # cljsjs (10)
- # clojars (25)
- # clojure (65)
- # clojure-austin (1)
- # clojure-brasil (2)
- # clojure-dev (33)
- # clojure-dusseldorf (6)
- # clojure-gamedev (3)
- # clojure-italy (17)
- # clojure-poland (3)
- # clojure-russia (7)
- # clojure-spec (48)
- # clojure-uk (45)
- # clojured (1)
- # clojurescript (26)
- # core-logic (2)
- # data-science (4)
- # datascript (6)
- # datomic (58)
- # defnpodcast (2)
- # docker (1)
- # duct (14)
- # figwheel (2)
- # fulcro (130)
- # graphql (3)
- # leiningen (1)
- # liberator (15)
- # luminus (5)
- # nrepl (1)
- # numerical-computing (1)
- # off-topic (45)
- # onyx (15)
- # re-frame (9)
- # reagent (3)
- # ring (1)
- # shadow-cljs (91)
- # spacemacs (8)
- # sql (23)
- # unrepl (38)
- # videos (2)
- # vim (12)
@devn https://clojure.github.io/spec.alpha/clojure.spec.alpha-api.html#clojure.spec.alpha/registry ?
@seancorfield that'll get me the spec objects by name, but not in a way that's easy to pluck out the req/opt
i have a feeling im just missing something obvious, maybe in how i define the :req to begin with. Is it possible for me to use a spec as the arg to :req
I wonder
Yeah, right now you'd have to get the form for each spec and then walk them.
Since the keys
part could be embedded deep inside a spec...
doesn't somebody mention a yet-to-exist spec spec every time this comes up?
Alex says they're looking at ways to make it easier to build specs programmatically but it's not there yet.
err, well, when it's a set, I can at least do (s/form ::the-keys)
and get back #{::a ::b}
, it's just that I can't use it in the s/keys
form
clojure.spec
is a wonderful concrete example of how macros don't compose đź‘€
im not complaining. i think there's probably a solution im missing here, let me try to be a bit more clear on what i want to do.
I have a spec which says that ::a
and ::b
are required.
I need some value holder that can be used both in the spec definition: (s/keys :req ...)
and a pull query (d/q '{:find [(pull ?blah ?the-qualified-keys) :in [$ ?the-qualified-keys]] ...} db the-qualified-keys)
err, i could relax that second part and say I'm not sure if that's possible. if it isn't, what kind of clever solutions are there? I suppose I could generate the spec and a corresponding def, for instance, so i don't have to manually keep modifications to either place consistent.
What we've done at work is to define a spec with keys, build any more complex specs on top of that, then get the spec form itself, parse out the :req [...]
part and pull the keys from that to use elsewhere. So the base spec was the "system of record" and we derived other stuff from it.
It's kind of icky but it works, given what we have available right now. It seems like the path of least resistance.
maybe (s/describe)
is good enough for what i want to do here, the structure of it just felt a little wonky to me: (keys :req [:foo/a :foo/b])
, so i need to do something like (apply hash-map (rest (s/describe ::the-map)))
or whatever
Hmm, we use s/form
... what is s/describe
?
Ah, an "abbreviated" form as data...
form: (clojure.spec.alpha/keys :req [:foo/a :foo/b])
describe: (keys :req [:foo/a :foo/b])
i'm surprised it's not a map, but perhaps there are Reasons™ why that I don't understand
getting a map isn't hard though: (apply hash-map (rest thing))
probably just a hint that it's not done yet
@alexmiller any details/insight about how could spec meta data look like in the future?
another question while I am at it: was it ever considered to implement (s/def ::foo ::bar) via clojure.core/derive
? I would personally find it quite interesting with that form, you can leverage ancestors/isa? etc
Not sure if Rich ever considered that.
Don’t know. The example above I would consider aliasing, not a hierarchy. The notion of derivation with respect to s/keys (containership) is interesting though for additive aggregations.
we use that on a small lib to add metadata to specs, we then can just say spec ::x derives from another and add useful little utils on top of that that can optionally fetch all the metadata from the ancestors and merge them for instance.
I filed https://dev.clojure.org/jira/browse/CLJ-2327 just to capture that slowdown
I think probably replacing the big set with a char int numeric check would probably help a lot
I don't think so @alexmiller -- it's OOMing which means some extra retention
if you replace the :atom branch with something like (defn atom-char? [c] (let [i (int c)] (or (<= 48 i 57) (<= 65 i 90) (<= 97 i 122))))
, I think you’ll find it doesn’t have the issue
it does not help at all @alexmiller
helped for me
oh, maybe I just did atom-char?
not (s/+ atom-char?)
yeah, prob