This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-16
Channels
- # announcements (7)
- # babashka (1)
- # beginners (25)
- # calva (7)
- # cider (15)
- # clj-kondo (13)
- # cljdoc (14)
- # clojure (151)
- # clojure-europe (4)
- # clojure-hamburg (2)
- # clojure-italy (22)
- # clojure-nl (57)
- # clojure-spec (12)
- # clojure-uk (6)
- # clojuredesign-podcast (5)
- # clojurescript (12)
- # core-async (8)
- # cursive (26)
- # datascript (9)
- # datomic (92)
- # emacs (4)
- # fulcro (7)
- # graalvm (1)
- # graphql (2)
- # instaparse (3)
- # jobs (1)
- # jvm (2)
- # kaocha (6)
- # nrepl (3)
- # off-topic (5)
- # re-frame (45)
- # reagent (5)
- # reitit (18)
- # ring (1)
- # shadow-cljs (89)
- # slack-help (9)
- # spacemacs (2)
- # sql (54)
- # tools-deps (75)
- # vim (28)
- # xtdb (17)
- # yada (31)
In spec 1 keywords are privileged with regards to s/keys
. I’d love for spec 2 to let me define other types of values to name key specs… e.g.
(s/defkey "foo" integer?)
(s/keys :req-key ["foo"])
I’m not actually so bothered by string keys, as what I’d really like to do is use URI’s as keys. My use case is that we work with RDF, and it’s really annoying having to convert between URI predicates and clojure keywords… I’d like to essentially do:
(def rdfs:label (URI. "http://,,,,#label"))
(s/defkey rdfs:label (s/or :xsdstring string? :langstring langstring?)
(s/def ::resource (s/keys :req-key [rdfs:label]))
Any ideas on whether this sort of thing might be possible in spec2?
implementing my own s/keys seems like it’ll be hard work
might there be an easy way to do it that can leverage stuff in spec?
the idea of keywords as names for specs is deeply embedded
not just s/keys but every spec impl relies on that
I wouldn’t mind having a layer of indirection between the name of the spec and the URI/key
we have no plans to make that
so would doing:
(s/def :rdfs/label (URI. ""http://,,,,#label"))
(s/def ::resource (rdf/keys :req [:rdfs/label]))
not be feasible?
it is possible that we might allow arbitrary metadata for specs. if we did that (and I'm not committing to it yet), then you could hang your mapping to a uri on that.
in the meantime you could create such a mapping outside spec if desired