Would also love to see the spec-aware fn, def, defn and defrecord utils somewhere. One thing I like most about Clojure(Script) is it's conciseness and Schema provided just that with it's schema-aware def(n)s & the plumbing defnk. The current fdef seems good for libraries, but feels noisy for apps. Some related links:
- https://github.com/plumatic/schema#beyond-type-hints - https://github.com/gfredericks/schpec/blob/master/src/com/gfredericks/schpec/defn%2Bspec.clj - https://github.com/plumatic/schema/issues/366 - https://github.com/metosin/spec-tools/issues/72 Hopefully there will be one good solution for this, for tools like Cursive to do static analysis on (as it does with the Schema syntax). Not sure if anyone is working on the spec-tools issue right now, looking forward to the Orchestra implementation. Meanwhile: https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html lauantai 23. syyskuuta 2017 21.42.13 UTC+3 Jeaye kirjoitti: > > Last I checked, on our Clojure back-end, instrumentation was taking up 2% > of our total test running time. This is with jdbc's instrumentation > disabled though; I think it's significantly slower due to its extensive > usage of s/or s/alt and spec regexes. Our specs are almost entirely s/keys > and clojure.core predicates. > > Our fn spec coverage is 47% on the back-end. So the performance impact of > instrumentation really hasn't been a concern. > > On Fri, Sep 22, 2017 at 10:18:52PM -0700, Didier wrote: > > > The goal is to add the macro to orchestra, as a tool to help encourage > spec'ing all functions. > > > > That would be great. My macro for now was also not supporting all defn > cases yet. And it automatically instruments the fn with orchestra. So if > orchestra had a more complete one defacto, I wouldn't need one. > > > > For performance, I've been thinking that caching validation (with some > configurable cache bounds), or having sample based validation, so > validating only a percentage of calls, and maybe even having the sampling > rate controlled by execution time metrics, or cpu metrics or call rates, > etc. would be interesting possibilities. So in prod, you could tweek the > validation to only get as much of it as you can afford. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clo...@googlegroups.com > <javascript:> > > Note that posts from new members are moderated - please be patient with > your first post. > > To unsubscribe from this group, send email to > > clojure+u...@googlegroups.com <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google > Groups "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to clojure+u...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
