I'm loving Spec as an FYI, and I'll use it even if it stays as is, even in its alpha state it is a great tool. I also highly value the Clojure core value to avoid breakage, as the cost to enterprise of every migration is very high.
I'm just wanting to give more data points to the Core team that I hope would be taken into consideration in the decisions of where to put the line on what Spec provides and doesn't. In my case, Spec has already not gone where my code base has. I'm sure there's use cases out there where a closed map spec would have been problematic, so I'm glad spec has an open map spec, but I've never had this problem, and I've failed to see anyone describe it to me where I felt the problem was real. What I do know is that I've experienced the problem of an open map spec that others have clearly described in this thread. When I need to validate for security that no extra keys were added to my maps, and when I want to be sure, for correctness, that my instrumentation is not accidentally not asserting my input because of a missing key spec, or if I want to be reminded that I forgot to update the spec when I extended the map to have additional keys, then clojure.spec falls short. I wouldn't ask of this to be taken into account by the core spec team, if it was easy to extend Spec to support this, but from what I could tell from the source, it is non trivial for me to add my own strict s/keys, and it doesn't seem possible to easily extend s/keys itself with more features. Especially if I want all the features of s/keys, except with strict key spec validation. I trust the core team to have good judgement, as they've shown to have with much of Clojure till date, but I think this is valuable data points for them to discuss and decide what's best. This was also part of a real enterprise project, that took 4 months with 5 engineers to develop. We're using it in production, so this is not feedback out of a toy project, or just experimentation. Maybe there's a better way to solve this problem then a strict spec, maybe we need a strict s/validate?, or some other more powerful and flexible construct. And maybe there are easy to extend spec for my needs, then I'd love to learn about those. Anyways, for the purpose of gathering data points about this use case. It currently seems like Me, Yury, Leon, Puzzler, and Tommi have all faced this issue. I've fixed it by doing my own validation on top of spec. So I only use spec as a data description language, and not as a validation tool. I use s/describe to get the keys, and then I resolve the specs, and assert that no more keys are on the map then what I got from s/describe. The downside is that I can't use instrumentation, assert, validate?, etc. So its hard to guarantee that the spec is always validated as my data should. The spec data description language is not powerful enough to be able to model invariants such as a closed set of keys, or keys which must have associated specs, unless I implement that predicate spec myself, which I couldn't figure out how to do. Since spec is still alpha, I think this is a great time to bring up these issues. On Tuesday, 3 October 2017 13:29:40 UTC-7, Tommi Reiman wrote: > > 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.
