On Tuesday, February 20, 2018 at 4:53:33 PM UTC+1, Alex Miller wrote: > > This is exactly why we recommend that you not use conformers for coercion. > Conformers were added primarily as a tool for building custom composite > spec types (for example, we used it to build keys* from keys). >
I am afraid that ship has sailed. Looking around I see lots of cases where people do use conformers for coercion. At a first glance it seems very natural, and warnings not to do it are not easily found. > This is a common need though and I would be happier if spec did more to > help you solve it in a way that minimized repetition and maximized the use > of existing specs. I'm still thinking through what that would mean exactly. > It's challenging right now to plug externally without rebuilding a > significant part of spec, so that's obviously not ideal. > > Ideally, you would be able to say the things that are important here: > > - the spec of the incoming data (strings or whatever - JSON sourced is the > major use case) > - the spec of the data I desire > - the coercion functions that can move from one to the other (there are > probably a small number of these that are widely reused) > - some way to coerce+validate or coerce+conform > > Building coercion into a single spec itself instead leads to the problem > of not being able to know what the source data actually was, and that's > really at odds with the spec philosophy and the notion of bidirectional > conforming. > I'm glad you see the need, highlighting it was largely the point of my post. As for these requirements, I agree, although I'm not sure about the need to know about the source. Regardless of larger future plans, I think my original suggestion still stands: it would be nice to have a function that would tell me if the data is valid as supplied. And another minor point: when I call a validation function (as part of contract checking), I do not necessarily expect to deal with all kinds of exceptions that coercion functions might throw. --J. -- 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.
