tiistai 20. helmikuuta 2018 19.05.55 UTC+2 Alex Miller kirjoitti: > > > On Tuesday, February 20, 2018 at 10:28:12 AM UTC-6, Erik Assum wrote: >> >> FWIW, I’ve been using https://github.com/metosin/spec-tools >> on a couple of projects lately, which helps nicely with >> conformance and coercion. The main devs are very helpful on #ring-swagger >> on the Clojurians slack. >> >> Alex, how does spec-tools measure up to your thoughts on >> conformance/coercion? >> > > spec-tools combines specs for your desired *output* with a coercion > function, making the spec of the actual data implicit. I feel like this > conflates too many things and obscures the actual input data value, which > is the same problem the original poster had. Also, spec-tools introduces > the notion of "type". spec intentionally avoids creating a new vocabulary > of special words like this and in all cases relies on predicates or things > mapped to predicates instead. I'm not a fan of this approach and I don't > like the idea in CLJ-2116 much either - I think it's pretty unlikely this > is where we will end up. >
I'm guilty of most parts of spec-tools and the CLJ-2116, so some comments. Spec-tools was built because there was a real-life problem (coercion) and spec didn't cover it. This was summer 2016 and there is still no official solution for this. New vocabulary, e.g. "type": everything besides coercion (json-schema mappings, form-resolution etc.) is already mapped directly to predicates and so could the coercion. Maybe we'll change that in next version. There will anyway be support to spec local configuration (for both coercion & spec transformation) via spec data: https://github.com/metosin/spec-tools/issues/96. In general, I think a lot of the functionality in spec-tools either uses > implementation internals that are almost certain to break as spec evolves > or is at odds with the philosophies of spec as stated in > https://clojure.org/about/spec (like the type vocabulary thing). > Hmmm... I know that data-specs use the functional (non-documented) version of the spec macros. They most likely will break at some point (but they are private in spec-tools too), but I guess the "functional specs" are anyway coming, so same things should be possible to do in the future, via just documented apis? There are lot of regression, and some progression tests <https://github.com/metosin/spec-tools/blob/master/test/cljc/spec_tools/visitor_all_test.cljc#L121-L123> too in spec-tools. I do see the problems driving this, and I agree there is a gap to be filled > here though. > This is good. There is also https://dev.clojure.org/jira/browse/CLJ-2251 by me, which would be my top1 wish for spec: one open `s/walk*` (replacing `s/conform*` and `s/unform*`) for specs and supporting different use cases: Would solve Jan's issues supporting just "validate", would bring first-class fast coercion (instead of current conform+unform is slow) and if it would be open, the support libs (like spec-tools) could extend by reusing the core, not by copying/rewriting. Could you comment on that Alex? Two-way coercion would be nice, but I think one-way coercion is ok too, much better than no coercion :) for JSON, Jackson can already write our Clojure back to JSON really fast, having a spec-transformation from clojure->JSON would be much slower anyway. -- 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.
