This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-31
Channels
- # admin-announcements (4)
- # alda (3)
- # aws (1)
- # beginners (2)
- # boot (33)
- # braid-chat (4)
- # braveandtrue (20)
- # cider (52)
- # cljs-dev (13)
- # cljsrn (55)
- # clojure (111)
- # clojure-belgium (4)
- # clojure-brasil (6)
- # clojure-dusseldorf (1)
- # clojure-greece (116)
- # clojure-mexico (1)
- # clojure-nl (3)
- # clojure-russia (56)
- # clojure-spec (72)
- # clojure-uk (13)
- # clojurescript (66)
- # community-development (2)
- # component (24)
- # core-async (1)
- # cursive (19)
- # datomic (27)
- # devcards (5)
- # emacs (1)
- # funcool (34)
- # hoplon (313)
- # jobs (1)
- # lein-figwheel (11)
- # luminus (5)
- # mount (30)
- # off-topic (63)
- # om (375)
- # onyx (67)
- # perun (8)
- # proton (1)
- # reagent (4)
- # rum (1)
- # specter (55)
- # spirituality-ethics (7)
- # test-check (2)
- # untangled (34)
- # yada (20)
How would one use spec with records, when records use unqualified keywords and spec mandates the use of namespaced keywords?
@kovasb: AFAIK, that doesn’t exist currently, but it should be possible to write from cribbing coll-of
@alexmiller: Ok thanks, I don’t fully understand the second option but I’ll investigate it.
I guess the obvious followup (maybe for #C06E3HYPR?) is: Are there plans to support exceptions in specs?
Given that the spec describe data structures, and function inputs/output — what would it mean to "support exceptions" in specs?
My first pass idea was just to "list the possible exceptions". But I'm totally open to the idea that that's just a bad idea.
I haven't thought it through or anything. Just noticed that I was hitting problems during generative testing because I couldn't declare that, say, arithmetic overflow, was an okay exception.
I can see pros and cons. Certainly in (unit) tests it can be valuable to say "given these inputs, I expect the following exception"...
But is that a failure to conform to its spec? It depends on whether the spec is considered to be "valid for all inputs that are valid" (and therefore "undefined" for invalid inputs)...
I just went through this exercise with java.jdbc
because there are lots of ways to generate exceptions from those functions… but I’m not sure how to specify that...
I’m not even sure if it makes sense to try to specify that? What if the DB is down, or the table you ask for doesn’t exist or there’s a syntax error in your SQL…? How would you codify that in clojure.spec
?
How could you even list all possible exceptions?
(each JDBC driver throws its own types — do you just say "could throw Exception"…?)
It’s a hard problem, either way. clojure.spec
definitely has gaps when you have stateful functions (generative testing on java.jdbc
functions isn’t possible in general — most garbage input will produce an exception, even if it is in the right "form").
I dunno, perhaps not since it's not exactly stopping you from doing anything at the end of the day.
@seancorfield: Yeah, spec is mostly not that useful for me either, for similar reasons.
So Sean and Nolen both seem to have created a my.lib.main-ns.spec
namespace to hold specs. Wonder if that will become a de facto place to put them for libraries.
I took that approach so that you didn’t have to load the spec ns — so you could use the code with Clojure < 1.9.0
Although the build system shot me in the foot since it compiles all namespaces(!).
Consequently, the build plain ol’ fails on Clojure < 1.9.0. Not sure how to approach that (make the entire namespace conditional? Ugh!).
@potetm: But you can’t have an optional namespace that uses spec and get it through the build system.
I already deal with conditional loading in the java.jdbc tests.
Locally, I can run lein test-all
and pass tests on every Clojure version from 1.4 to 1.9 — and only on 1.9 does it use the spec.
But the contrib build system tries to compile the namespaces in the project… So maybe there’s some Maven incantation I can use to exclude the namespace from compilation (or whatever Maven is trying to do with it).
http://build.clojure.org/job/java.jdbc-test-matrix/410/ and http://build.clojure.org/job/java.jdbc-test-matrix/410/CLOJURE_VERSION=1.4.0,jdk=OpenJDK%201.6/console
Well except for this problem, that tool seems pretty slick 🙂 I've never seen anything like it before.
Maybe someone can make a hacked-up stub do-nothing compatibility lib in the clojure.spec
and cljs.spec
namespaces that consumers on 1.8 can use, just so things can be loaded. Ugh.
@potetm: Have you looked at core.typed or Prismatic Schema at all?
No I mean the version matrix. All the JDKs all the clojure versions. A really nice idea for open tooling. (I've always had control over JDK and clj versions.)
Tomorrow I’ll talk to @alexmiller about the build system and see if we can figure out something ...
Sean: 1, Maven: 0 😈 So it turns out a contrib project can override the parent pom.xml
and suppress the Maven-initiated compile phase: https://github.com/clojure/java.jdbc/commit/b224a3e86df8c00a33a16122e6fcc531c5f71e2e
Now I feel dirty for having to learn that much about Maven 😞
Apparently if I want to get really "clever" I could probably create a conditional profile based on the Clojure version and have it still run compile if we’re using 1.9.0… Ugh! <profiles>
...
@seancorfield: lein's {:aot :all}
doesn't kick in for included dependencies, did it? Maybe that's the reason for maven
compile's strategy
@anmonteiro You had an example of clojure.test
integration were you used spec-is
. I can’t find spec-is
in the sources. I’m also interested in a proper clojure.test
integration of clojure.spec.test/check-var
. clojure.spec.test/run-tests
only works in the REPL for me. I need it in leiningen.
@akiel: spec-is
was something I wrote:
(defmacro spec-is [res]
`(clojure.test/is (true? (:result ~res))))
@anmonteiro: ok thanks this works.
@anmonteiro: I’ve extended the is
macro in the following gist. This looks even better to my eyes. https://gist.github.com/alexanderkiel/931387c7a86c1879b2267ad064067af7
@andrewhr: The pom.xml
file indicates the compile is just a "sanity check" so I’m taking that as "optional"...
Is there anything in between s/keys and s/map-of for heterogenous maps --- maps with keywords and structured values as keys?
As I spec’d java.jdbc
I found myself wanting a way to constrain the values of the optional keys in the optional opts
argument. I suspect the only way is (s/and (s/keys …) #(some custom predicate))
?
(I’d have to take a look at what s/keys
conforms values to)
Are you guys tending to write your fdef
s in a separate ns or in the same ns above/below where the function is written?
How would one spec a map with non-keyword keys and heterogenous values (the specs of which are dependent on the keys)?
That is, how would you spec ::person
from the guide if ::first-name
::last-name
etc were strings?
Or, to put it another way, is there a version of clojure.spec/keys
that works with non-keyword keys?
@zane: I suspect you’d need to say (s/map-of string? ::s/any)
and then have some custom predicate on the conformed value.
@kenny: I think overall I’d prefer data structure specs in a separate ns and fdef
alongside the functions themselves but I won’t have a solid feel for that until we’ve used it a bit more heavily.
In clojure.java.jdbc
, I put all the specs in a separate ns so users on Clojure < 1.9.0 could still use the library.
@seancorfield: If I wanted to try to recover the the features of clojure.spec/keys
but for maps with non-keyword keys would you recommend I implement clojure.spec/Spec
myself?
I suspect that will be a lot of work (but I haven’t looked at it). Since the push is for namespaced keywords — but unnamespaced keywords are also supported — I guess I would have to question your desire to define an API based on maps with non-keyword keys?
By which I mean, what specifically is it that you’re trying to spec out here that isn’t a "regular" Clojure map?
(and, perhaps therefore, spec "at large" is not designed for your use case?)
My sense with clojure.spec
is that it’s opinionated deliberately to encourage a particular style of API specification… "idiomatically Clojurey"… The comments in particular about namespaced keywords being "tragically underutilized" and that namespace-qualified keywords is "a practice we’d like to see grow"...