Looking around I see lots of cases where people do use conformers for coercion.
That doesn’t make them right 😊 At a first glance it seems very natural, and warnings not to do it are not easily found. Every single time coercion comes up anywhere in the context of spec, someone says “don’t do that”, and they’ve been saying it since the earliest alpha versions of spec. You would be correct to point out that nothing in the spec overview or spec guide on clojure.org carries this caution, however (and I think it’s a reasonable “ask” for the guide to be updated to include such a caution). My recommendation is to have a strictly non-coercive spec for the target data “type” / shape you want, and to have a second spec that combines the coercion you want with that spec. That way you have a way to tell if your uncoerced data conforms to the spec, as well as a way to do coercion in s/conform. They are – and should be – two separate specs and two separate operations. They represent different layers of abstraction inside your application (so “of course” they should be two separate specs, one built on top of the other). Given that the overview and the guide don’t even mention s/conformer, I’m not sure where that recommendation should live. Alex, any thoughts on this, since you seem to be the one most often making the recommendation? Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ________________________________ From: clojure@googlegroups.com <clojure@googlegroups.com> on behalf of Jan Rychter <jrych...@gmail.com> Sent: Wednesday, February 21, 2018 1:16:49 AM To: Clojure Subject: Re: s/valid? does not tell me if the data is valid as supplied 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<mailto: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.
