[ANN] Clojure 1.9.0-alpha8
1,736 views
Skip to first unread message
Alex Miller
Jun 28, 2016, 6:13:25 PM6/28/16
to Clojure
Clojure 1.9.0-alpha8 is now available.
Try it via
- Dependency: [org.clojure/clojure "1.9.0-alpha8"]
1.9.0-alpha8 includes the following changes since 1.9.0-alpha7:
The collection spec support has been greatly enhanced, with new controls for conforming, generation, counts, distinct elements and collection kinds. See the docs for every, every-kv, coll-of and map-of for details.
instrumenting and testing has been streamlined and made more composable, with powerful new features for spec and gen overrides, stubbing, and mocking. See the docs for these functions in clojure.spec.test: instrument, test, enumerate-ns and summarize-results.
Namespaced keyword reader format, printing and destructuring have been enhanced for lifting namespaces up for keys, supporting more succinct use of fully-qualified keywords. Updated docs will be added to clojure.org soon.
Many utilities have been added, for keys spec merging, fn exercising, Java 1.8 timestamps, bounded-count and more.
Changelog:
clojure.spec:
- [changed] map-of - now conforms all values and optionally all keys, has additional kind, count, gen options
- [changed] coll-of - now conforms all elements, has additional kind, count, gen options. No longer takes init-coll param.
- [added] every - validates a collection by sampling, with many additional options
- [added] every-kv - validates a map by sampling, with many additional options
- [added] merge
- [changed] gen overrides can now be specified by either name or path
- [changed] fspec generator - creates a function that generates return values according to the :ret spec and ignores :fn spec
- [added] explain-out - produces an explain output string from an explain-data result
- [changed] explain-data - output is now a vector of problems with a :path element, not a map keyed by path
- [added] get-spec - for looking up a spec in the registry by keyword or symbol
- [removed] fn-spec - see get-spec
- [added] exercise-fn - given a spec'ed function, returns generated args and the return value
- All instrument functions moved to clojure.spec.test
clojure.spec.test:
- [changed] instrument - previously took a var, now takes either a symbol, namespace symbol, or a collection of symbols or namespaces, plus many new options for stubbing or mocking. Check the docstring for more info.
- [removed] instrument-ns - see instrument
- [removed] instrument-all - see instrument
- [changed] unstrument - previously took a var, now takes a symbol, namespace symbol, or collection of symbol or namespaces
- [removed] unstrument-ns - see unstrument
- [removed] unstrument-all - see unstrument
- [added] instrumentable-syms - syms that can be instrumented
- [added] with-instrument-disabled - disable instrument's checking of calls within a scope
- [changed] check-var renamed to test and has a different signature, check docs
- [changed] run-tests - see test
- [changed] run-all-tests - see test
- [changed] check-fn - renamed to test-fn
- [added] abbrev-result - returns a briefer description of a test
- [added] summarize-result - returns a summary of many tests
- [added] testable-syms - syms that can be tested
- [added] enumerate-namespace - provides symbols for vars in namespaces
clojure.core:
- [changed] - inst-ms now works with java.time.Instant instances when Clojure is used with Java 8
- [added] bounded-count - if coll is counted? returns its count, else counts at most first n elements of coll using its seq
Daniel Compton
Jun 28, 2016, 6:37:22 PM6/28/16
to Clojure
I know these were just changed from map-of and coll-of, but the names every and every-kv seem a little confusing. every and every-kv only sample from collections, whereas the name implies that everything in the collection is checked. Additionally, there is an every? in clojure.core which does check a predicate for every value in the collection.
I (loosely) suggest sample and sample-kv as other names, but am not 100% sure I like them.
Thoughts?
--
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
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
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.
For more options, visit https://groups.google.com/d/optout.
--
—
Daniel
Alex Miller
Jun 28, 2016, 7:39:59 PM6/28/16
to Clojure
The "every" part refers to requirement, not enforcement. Here "every" means that this is what the rule is (and not about how you verify them). I don't want to bikeshed the names - they have been discussed at length and they're not going to change.
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--—Daniel
Leon Grapenthin
Jun 28, 2016, 7:44:30 PM6/28/16
to Clojure
I welcome the current naming because for the naming to be consistent it is also necessary that names and forms of spec describe what is expected of specified data.
In fact every does require every element to conform to a spec, not just some so it is semantically correct.
(s/sample (s/and number? pos?)) as spec for the return value of (range) lacks the clarity of (s/every (s/and number? pos?)).
Leon Grapenthin
Jun 28, 2016, 7:48:26 PM6/28/16
to Clojure
This is fantastic. Spec really seems to turn out like a "killer-feature" for Clojure.
Colin Fleming
Jun 28, 2016, 10:39:58 PM6/28/16
to clo...@googlegroups.com
Is there a JIRA with details on the namespaced keyword changes?
Alex Miller
Jun 28, 2016, 10:48:07 PM6/28/16
to Clojure
The two jiras are here:
I'll be working on updating clojure.org docs tomorrow.
Alex
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+unsubscribe@googlegroups.com.
Alex Miller
Jun 28, 2016, 10:49:20 PM6/28/16
to Clojure
I've updated the spec guide for Clojure 1.9.0-alpha8 and I will add some more to it later about s/merge and probably some on the new instrument mock/stub capabilities.
Alex
Simon Belak
Jun 29, 2016, 9:57:49 AM6/29/16
to Clojure
map-of now conforming is fantastic news!
One question though: why doesn't every validate when given nil for collection? Seems inconsistent given pervasive nil punning elsewhere and that [] validates.
s
On Wednesday, June 29, 2016 at 12:13:25 AM UTC+2, Alex Miller wrote:
Alex Miller
Jun 29, 2016, 10:02:43 AM6/29/16
to Clojure
user=> (s/explain (s/every ::s/any) nil)
val: nil fails predicate: coll?
indicates that s/every (also s/coll-of) validate using coll? as the predicate and coll? (like most type predicates) does not validate nil.
nil punning is more often done for sequences. Sequences with structure are typically speced using regex ops, which does validate on nil.
user=> (s/valid? (s/* ::s/any) nil)
true
Alex Miller
Jun 29, 2016, 10:03:54 AM6/29/16
to Clojure
Also, you can turn any predicate into a nil-accepting predicate with s/nilable.
user=> (s/valid? (s/nilable (s/every ::s/any)) nil)
true
Simon Belak
Jun 29, 2016, 10:12:41 AM6/29/16
to clo...@googlegroups.com, Alex Miller
Missed that s/nilable exists. Cheers.
--
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
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/vF3RuDWuX8I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages