This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (20)
- # cider (59)
- # cljsrn (6)
- # clojars (7)
- # clojure (91)
- # clojure-boston (1)
- # clojure-dusseldorf (3)
- # clojure-finland (1)
- # clojure-italy (8)
- # clojure-losangeles (1)
- # clojure-nl (16)
- # clojure-spec (25)
- # clojure-uk (113)
- # clojurescript (126)
- # core-async (27)
- # cursive (5)
- # data-science (3)
- # datomic (22)
- # emacs (24)
- # fulcro (30)
- # garden (7)
- # graphql (7)
- # leiningen (3)
- # nginx (1)
- # off-topic (63)
- # onyx (13)
- # portkey (1)
- # re-frame (1)
- # reagent (28)
- # shadow-cljs (92)
- # tools-deps (1)
- # uncomplicate (1)
- # vim (24)
- # yada (8)
Gary talked about an interesting issue recently. What if you instrument all and there are loads of fdefs for core functions. This will create a lot of validation overhead. Anyone experienced this becoming an issue?
Currently, no core functions are spec’ed (just macros, which are done at compile time not runtime, although admittedly those are often pretty close together in repl dev). Having too much instrumented definitely can create a noticeable effect.
There's definitely overhead. By rights it shouldn't matter so much at dev time which is the common use case for instrumenting.
it'll matter if specs get added to clojure core fns; I can easily imagine a 10000x slowdown depending on what you're doing
I recently started using spec and I wanted to know the reason behind why
s/and conforms values and propagates them.
I hadn't read the spec guide (https://clojure.org/guides/spec#_spec_ing_functions) in full before I found the first example of this in our code base and I found it hard to read.
conforming tells you not just whether something validated (like
valid? but how it validated - indicating which alternatives are taken and how value components were parsed). Flowing conformed values allows
s/and to also flow conform info out to the user from internal components (which is also done in most other conforms)
Is it possible to "redirect" a failure. For example, if a list of numbers must be sequential, this validation can only be performed on the "whole", but the failure is on a particular index.
not without implementing your own spec
@alexmiller is that api private currently?
it’s public but undocumented and subject to violent change
as in, I expect it to change, and possibly even be completely replaced.
things like spec-tools are using it extensively
Spec protocol will be replaced? Is it possible to comment or discuss on the upcoming changes, from 3rd party library maintainer perspective?
no, I don’t know yet what they will be
it may be replaced, it may not be replaced, it may change, I have no idea yet
this is the alpha part of spec.alpha
my advice right now would be - don’t use that
I expect changes to the main user api of spec to be minimal or at least well thought about
ok. thanks. there is a alpha disclaimer too on spec-tools, but just checked, it has 13k downloads, so someone is using that already. hopefully there is a way to port the features to new spec apis - or remove stuff that is implemented by the new core directly.
I have not been shy about telling spec-tools and others what I said above
spec-tools is almost certain to be broken by future spec changes
I don’t agree with most of what that library is doing