Open Specs seem like a good idea. In real life, we need to close our Data at system borders.
With Java, there is Jackson, which fails by default on extra keys. The Schema, the models are closed by default. JSON Schemas can be closed. Saying "use normal clojure" on top of Spec mean double-validation, which is both error-prone and boilerplate. Open/Closed is a great principle. Spec should be just more Open to allow people (or 3rd party libs) to extend it to support "close my (open) specs" at runtime = coercion. If Runtime Transformations stay out of scope, It would be good to have a guide on how to write Spec + (beautiful) clojure transformations for web/ring apps. There might be tricks we just haven't thought of. cheers, Tommi tiistai 3. lokakuuta 2017 20.57.34 UTC+3 Alex Miller kirjoitti: > > > > On Tuesday, October 3, 2017 at 12:25:40 PM UTC-5, Didier wrote: >> >> | Spec-tools (https://github.com/metosin/spec-tools) has some tools for >> this: the spec visitor (walking over all core specs, e.g. to collect all >> registered specs) and map-conformers: fail-on-extra-keys and >> strip-extra-keys. >> >> I understand the core team wanting to take a minimal approach to spec, >> and that open is easier to restrict later. >> > > It's not about easier, it's about possible. Open grows, closed breaks. > > >> But I worry that already in alpha state, spec is unpractical for many >> people as is >> > > This is demonstrably false. Many people are using it and happy with it now. > > >> , and Orchestra and Spec-tools are already needed supplement. >> >> For instrumentation, it's no big deal, but for specs I think it is. >> Having a canonical set of specs accross Clojure shops is a way to form a >> common language. If I start having my custom map specs, and so does >> everyone, I'd be tempted to say something core is missing. Strict map specs >> which also vallidates each key has a registerer spec I think is a glaring >> omission. >> > > I'm not sure how to say this other than that we are playing a longer game > than you, looking out into the future to other potential functionality and > where code bases are likely to go over time. > > We have already seen a number of cases where strict map specs broke during > evolution both inside and outside Cognitect projects as people added keys. > Again, nothing prevents you from both validating your spec AND applying > whatever additional validation you wish to perform. But if you put the > strict check into the spec, you have poured concrete on the spec and it is > dead. > > >> Having used spec in one of my design, I've had to justify already to 6 >> people, some being senior security engineers, why the validation allows for >> open keys. >> > > Those other people are right - you should check that if it's important. > But it doesn't have to be part of the spec. Specs should say what must be > true (open), not what MUSTN'T be true (closed). This is in some ways > another variant of the open/closed principle (the O in SOLID). > > >> Other team members were just confused as to why that was, and the only >> argument I had was that Rich doesn't like to break APIs :p. >> > > This is an exceptionally good argument. Why would you dismiss it? > > >> But I've had to add validation on top to pass security audit. >> > > Good! > > >> So I think while not breaking APIs when incrementally adding specs to >> legacy code is a good use case, there's the security and safety use case >> which seems to be shared by a large swat of Clijurist, and I think spec is >> in need of a core support for it. >> > > No, it doesn't! Spec doesn't have to do everything. We've got this whole > beautiful language to use. > > -- 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.
