This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-10
Channels
- # ai (2)
- # beginners (3)
- # boot (113)
- # bristol-clojurians (2)
- # cider (77)
- # clara (43)
- # cljs-dev (48)
- # cljsrn (9)
- # clojure (319)
- # clojure-austin (2)
- # clojure-czech (4)
- # clojure-denmark (4)
- # clojure-france (4)
- # clojure-italy (4)
- # clojure-russia (2)
- # clojure-serbia (10)
- # clojure-spec (79)
- # clojure-uk (64)
- # clojurescript (109)
- # clr (3)
- # conf-proposals (21)
- # core-async (19)
- # cursive (26)
- # datascript (11)
- # datomic (19)
- # devcards (1)
- # emacs (25)
- # figwheel (9)
- # hoplon (31)
- # jobs (7)
- # jobs-discuss (14)
- # leiningen (10)
- # lumo (11)
- # off-topic (37)
- # om (40)
- # onyx (4)
- # perun (8)
- # planck (3)
- # rdf (4)
- # re-frame (40)
- # ring (11)
- # ring-swagger (2)
- # rum (21)
- # spacemacs (2)
- # specter (50)
- # untangled (93)
- # yada (13)
turns the vector of tags into a set, so the multispec can use the set as a predicate function for the multimethod dispatch
this way I can combine multiple defmethods
. If we take the example of :event/type
from the official clojure spec guide, then I could do:
{:event/type [:event/search :event/error]
:event/timestamp 1463970123000
:error/message "Invalid host"
:error/code 500
:search/url ""}
Yeah, there are no constraints on multi-spec as long as you follow the pattern
In docs for s/keys there is “Note: there is no support for inline value specification, by design.”. Does some expanded explanation of this exist somethere?
is it possible to specify spec for value referred by specific key in the map? I.e I want to say that {:id “my-id”} “my-id” should be validated by spec ::resource-id
currently if you use s/keys there is only implicit assignment of the spec in case the keys are same
@dragoncube there is some additional info about that at http://clojure.org/about/spec
re rationale that is
re the second question, the key must match the spec name
the idea here (also in the rationale) is that we are assigning enduring semantics to an attribute that can be used throughout the system
it is admittedly a different philosophy than something like Schema
yeah, but it is quite hard to work with the external data which shape you don’t control
for example, {:id “res-1” :name “My resource 1” :sub {:id “sub-res-1” “Sub-resource 1"}}
should I use synthesized keys for registering specs or I need to mimic data structure with packages structures?
It is so tempting to use :: for specs registration
for example above I would like to register two specs: ::resource-id and ::sub-resource-id in the same namespace
well you can certainly do that along with s/keys and :req-un which will only match the name part, not the namespace part
yes, it is possible but in this case you need either give it synthesized (not existing) namespace part like :rest-resources/id and :rest-resources.subresource/id or literally create ‘subresource’ package and define ::id spec there
both of these are far from ideal
Agreed :)
Rich is as well I think but hasn't decided how it should be implemented yet
how do people feel about something like this:
(defn coerce
[spec data]
(let [conformed (s/conform spec data)]
(if (= :clojure.spec/invalid conformed)
conformed
(s/unform spec conformed))))
I've been avoiding conform == coerce, after getting bitten, but this has got me thinking of dabbling again.I wish the :gen
overrides of stest/instrument
behaved the same way as the :gen
of stest/check
hey all, quick q about how instrument
and check
work in cljs.
I’m running a figwheel repl in cursive. the repl is choking and timing out when I eval an instrument
or check
call for an fdef
‘ed function . further evaluations – even of simple forms (e.g. (+ 1 1)
– then result in an eval timeout.
posted in the figwheel channel already but feel like I might just be misunderstanding a core spec concept and how I’m supposed to use it
that sounds weird
instrument should not take a long time to execute
check certainly can take a while as it runs 1000 tests by default - you can change that by passing it additional options. although most often adjusting your generators is what really needs to happen.
yeah it feels like I must be doing something wrong.
fwiw my spec is just a set of a few dozen string values (i.e. (cljs.spec/def ::my-spec #{”something” “something-else” …})
.
my fdef
looks something like
(cljs.spec/fdef my-bool-returning-func
:args (s/cat :my-spec-val ::my-spec)
:ret boolean?)
simply calling "cljs.spec.test/instrument `my-bool-returning-func”
or “cljs.spec.test/check `my-bool-returning-func” causes the same choking behaviorI am looking at using spec for validation for a SPA app. I am hoping that I can use the same specs for both the front and backend. I am guessing that I would place them in a cljc file, but I was wondering how the s/def would work with s referring to clojure.spec and cljs.spec. Any ideas?
what’s the preferred idiom to “optionalize” some map with :req keys? specifically, something like (s/merge ::foo (s/or ::bar (s/keys)))
@assoc-in the new cljs feature for automatic aliasing means that I think you can just use the clojure namespace in the cljc file and it will work for both
but you should check with David in #clojurescript
@bbloom not sure I understand what you’re asking?
@alexmiller to make a simplification of what i’m doing concrete: imagine i have some spec (s/def ::syntax (s/keys :req [::line ::column]))
and i have some other AST nodes that might or might not have line/column information on it: (s/def ::ast (s/keys :req [::type ::op ::whatever] :opt [::line ::column]))
however, i have it’s not just two fields, it’s quite a few and i want to basically say “an ast node is these keys and optionally a ::syntax"
you could define ::syntax
with :opt
instead and just s/merge
?
ideally not, since the parser requires everything be a ::syntax with proper line and column info
then why did you say optionally above?
in that case, just merge ::syntax
and ::ast
?
@alexmiller okay thanks I'll ask
ie not every node that comes out of the analyzer has line/col info on it - but in the parser, it is required
i don’t really want :opt tho, since if there is a ::line, i expect there to also be a ::column
why do you need to do anything in the analyzer? the s/keys
you already have in ::ast
will validate those
I don’t think there is a way to do it in keys, so you’d need an extra constraint
i figured as much 🙂 was wondering if there was a particular pattern that has been successful for this sort of thing
don’t think I’ve seen it
I think I would leave the :opt in ::ast to get gen and and that with a custom predicate
the pred should filter any generated maps that don’t satisfy the pred
in gen that is
@alexmiller Thanks I asked David and he said I can just use clojure.spec everywhere in the cljc file and I'll be good to go. I am really happy to see that spec's will be usable across both clojurescript and clojure so easily
@alexmiller here’s what i want to work 🙂 https://gist.github.com/brandonbloom/5d89fe87cb6fe34844423f9e88939085