This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-26
Channels
- # admin-announcements (2)
- # aws (1)
- # beginners (21)
- # boot (61)
- # cider (5)
- # cljs-dev (94)
- # cljsrn (35)
- # clojure (106)
- # clojure-austin (3)
- # clojure-belgium (1)
- # clojure-dev (4)
- # clojure-dusseldorf (9)
- # clojure-greece (2)
- # clojure-mexico (1)
- # clojure-russia (40)
- # clojure-spec (61)
- # clojure-uk (17)
- # clojurescript (151)
- # code-art (1)
- # component (7)
- # core-async (4)
- # cursive (1)
- # datomic (9)
- # dirac (55)
- # funcool (12)
- # hoplon (118)
- # incanter (12)
- # jobs (8)
- # juxt (1)
- # lein-figwheel (6)
- # mount (2)
- # off-topic (2)
- # om (76)
- # onyx (28)
- # other-lisps (1)
- # planck (7)
- # re-frame (9)
- # reagent (13)
- # ring-swagger (2)
- # specter (1)
- # yada (22)
tuple is not a parameterized coll (see coll-of for that), (tuple number?) says vector of exactly one number
tuple is for short tuples of heterogeneous types each of which will be listed
@richhickey Oh hi! My comment is about the message, not that it should pass…
e.g. (tuple string? number?)
vs what?
I was reading the rationale document as saying that we want to capture the predicates the user supplied, so I was hoping for something like: val: [] fails spec: (tuple number?).
that doesn’t tell you much
and the interior preds can be arbitrarily complex, will walk down
much better than “you failed the top"
Hrmm. So my (clearly not thought through) expectation would be that count would fail at tuple, but sub-types would fail more specifically. That’s not an idea I can make coherent, though.
have fun!
is it possible create a spec for a map like {[300 200 54] :status/open} e.g. map keyed by vector of integers
@shaunxcode yes I believe so using map-of
Should I include test.check as an explicit dependency when using spec? I got: FileNotFoundException Could not locate clojure/test/check/generators__init.class or clojure/test/check/generators.clj on classpath. clojure.lang.RT.load (RT.java:456)
when instrumenting the adder
example from the guide https://clojure.org/guides/spec (cc @alexmiller )
@borkdude: Yes, you need it for most cases if you want to use spec in your tests. There was only one function that works without test.check (I think it was spec/gen, but not sure). I have read it somewhere in the official docs in the last days.
@anmonteiro: wrapping it in (s/spec...
doesnt fix it unfortunately
Also, what works is:
(s/conform ::columns [{:foo "some_t"}])
=> {:col [{:foo "some_t"}]}
which is strange, cause all I do next is to put it into the argument definition of my functionIs there space in spec, for a specification to take parameters via lexical scope? This may be out of scope for spec.
For example, on http request, I take a snapshot of my database, and I want to check if a value is in that database. But I want to have my predicates registered via s/def
so that I can take advantage of :via
and such.
Use case is checking if an email is taken during user registration.
Library authors might want to add specs to their existing projects but also keep supporting earlier versions of Clojure
Is this a use case that has been thought about, or isn’t there any interest in supporting such use case?
or are we just supposed to solve it through versioning?
Specs could be provided in an adjunct library too
Ultimately, things must move forward to get the benefits of new features as we did with records, protocols, transducers, reader conditionals, etc etc
Agreed wrt. 2nd point
and yea, the optional library add-on could also be a possibility for initial compatibility, hadn’t thought about that
thanks
@anmonteiro: having spec in both clojure.core + an external library could cause namespace conflicts
They can also be in a separate namespace in your library jar that's just not loaded (unless you're on 1.9)
@bronsa: I understand, but I didn’t mean that.
1.9.0-alpha3 is now out with several bug fixes and improvements for spec https://groups.google.com/forum/#!topic/clojure/WxT9kPIwlYI
The guide is now out of date but I will have it updated shortly
@alexmiller: Is there much of a story for what I mentioned previously? https://clojurians.slack.com/archives/clojure_spec/p1464256334000558 Trying to decide how to approach the problem of generating/validating forms.
@dominicm: you could register (at runtime) an s/def that partialed/closed-over something known at runtime like a database snapshot. This implies that you are using spec to do runtime data validation. Whether or not this is a good idea, I'm not sure. :)
@alexmiller: Yeah, I did wonder if dynamic vars might be a solution, and a bad idea. I'm definitely thinking in the domain of variable user-input, as opposed to contracts during development. I like the idea of spec as a ubiquitous format that the clojure community uses to describe data. Some data just can't be controlled (user input). Maybe this is way out of scope for spec though, and you guys think that should be a different library altogether. There's definitely a lot of overlap in that space (email still needs to be a string, over 5 chars, match a regex, before it is db checked). Nothing says a validation library can't register things for you of course. But I try to keep core at the top, not other libraries.
The registry itself is pretty simple, I think a 3rd-party lib could sub out the behavior you want but use registered specs along the way.
@gtrak: Yeah, that's what I was thinking about. But if it is in scope for spec, that would be pretty cool.
my understanding so far is that spec itself is mostly concerned with the lib-sharing/transmission/self-describing-edn use-cases, but there are a lot of developer-convenience type cases we'd also want to use it for (overlap with Schema), but it can't integrate all of them.
For instance, the first thing I wrote was a multimethod type->spec coercer, which is a special case extension of the built 'conform', I wouldn't expect that to get into clojure.spec, but I might expect it to be available as a lib, since it's so easy to write.
the one thing I'd request from clojure.spec itself was a way to provide a better error message than what s/conformer creates, which in this case is too generic, a failure in the pred: (fn [from] (coerce from to))
. It's possible I can do so by dropping down a level in abstraction but haven't gotten that far.
@gtrak: oh I agree! I had wondered if that would be possible! Shame you beat me to it. But I feel like being unable to lexically scope a spec in some way hinders me a little. Maybe I'm looking at it wrong, or maybe I can come up with a clever roundabout way to do it and lib it up.
I think I overheard that specs are serializable somewhere, so lexical scope could really mess that up.
I probably shouldn't refer to scope. What I want is a solution to the problem of runtime values effecting the running of my predicates, without relying on state. Am I making sense?
I don't see how it's possible to do that without state, maybe a dynamic/threadlocal registry, but then the state's in the registry.
@alexmiller: I just found a possible bug in the following snippet:
Running lein test
for this code will run into a never ending loop when it tries to test leiningen.s-play-test
The cause is this line (s/fdef foo :args (s/cat))
with the incomplete (s/cat) expression.
Feel free to file a jira for it