On Tuesday, May 24, 2016 at 12:16:32 AM UTC-5, Sean Corfield wrote: > > I was a bit puzzled by the :req-un / :opt-un stuff in maps. Am I right > that there is a requirement here for the keys to be namespaced but the > actual namespace is completely irrelevant / ignored? >
No - the :req-un / :opt-un keys are used for two purposes: 1. The namespaced key is used to locate the spec in the registry 2. The unnamespaced key is used to find the value in the map Once those are found, the spec is used to validate the attribute value. > > > (defn thing [m] > > (+ (:a m) (:b m) (or (:c m) 1))) > > (s/fdef thing > > :args (s/cat :map (s/and (s/keys :req-un [:x/a :y/b] > > :opt-un [:z/c]) > > (s/map-of keyword? number?))) > > :ret number?) > > > > I tried several namespace prefixes here and it seemed I can use anything > and they don’t even need to be consistent. > Right - if no spec is found then nothing happens. But if you registered a spec as :x/a or :y/b those specs would be used to validate the arg. > > Wouldn’t it be easier to just allow un-namespaced keywords here? Or is > there some aspect of the namespacing here that I’m missing? > > > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org > > > > *From: *Rich Hickey <richhic...@gmail.com> > *Sent: *Monday, May 23, 2016 7:12 AM > *To: *clojure@googlegroups.com > *Subject: *clojure.spec > > > > Introducing clojure.spec > > > > I'm happy to introduce today clojure.spec, a new core library and support > for data and function specifications in Clojure. > > > > Better communication > > > > Clojure is a dynamic language, and thus far we have relied on > documentation or external libraries to explain the use and behavior of > functions and libraries. But documentation is difficult to produce, is > frequently not maintained, cannot be automatically checked and varies > greatly in quality. Specs are expressive and precise. Including spec in > Clojure creates a lingua franca with which we can state how our programs > work and how to use them. > > > > More leverage and power > > > > A key advantage of specifications over documentation is the leverage they > provide. In particular, specs can be utilized by programs in ways that docs > cannot. Defining specs takes effort, and spec aims to maximize the return > you get from making that effort. spec gives you tools for leveraging specs > in documentation, validation, error reporting, destructuring, > instrumentation, test-data generation and generative testing. > > > > Improved developer experience > > > > Error messages from macros are a perennial challenge for new (and > experienced) users of Clojure. specs can be used to conform data in macros > instead of using a custom parser. And Clojure's macro expansion will > automatically use specs, when present, to explain errors to users. This > should result in a greatly improved experience for users when errors occur. > > > > More robust software > > > > Clojure has always been about simplifying the development of robust > software. In all languages, dynamic or not, tests are essential to quality > - too many critical properties are not captured by common type systems. > spec has been designed from the ground up to directly support generative > testing via test.check https://github.com/clojure/test.check. When you > use spec you get generative tests for free. > > > > Taken together, I think the features of spec demonstrate the ongoing > advantages of a powerful dynamic language like Clojure for building robust > software - superior expressivity, instrumentation-enhanced REPL-driven > development, sophisticated testing and more flexible systems. I encourage > you to read the spec rationale and overview http://clojure.org/about/spec. > Look for spec's inclusion in the next alpha release of Clojure, within a > day or so. > > > > Note that spec is still alpha, and some details are likely to change. > Feedback welcome. > > > > I hope you find spec useful and powerful! > > > > Rich > > > > -- > > 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. > > > -- 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.
