On Monday, December 19, 2016 at 2:42:49 PM UTC-6, Josh Tilles wrote: > > Hi all, > > On several occasions, Alex Miller has emphasized that we should be wary of > “baking in” conformers when defining specs. I agree with him, but it’s not > clear to me how to “opt in” to using conformers on map vals. As far as I > can tell, I’m either limited to using unqualified keys —which enables > swapping specs from alternative namespaces for a given map-entry— or > adapting any conformer to operate on the whole map (e.g., with update) > rather than the val of a map-entry directly. > > So, some questions: > > 1. Am I missing something? Is there actually a way to specify > conformance *à la carte* for the vals of a map with qualified keys? If > not… > > You're not missing anything.
> > 1. Is there a plan to add this functionality? (I would be happy to > create a JIRA issue if it would be better to take this conversation > there.) > If not… > > In the way that you seem to be envisioning it, probably not. > > 1. Is this seen as an acceptable tradeoff of an API that the core > Clojure devs are otherwise happy with? Or is it in fact a *deliberate* > limitation, > in line with the “map specs should be of keysets only” > <http://clojure.org/about/spec#_map_specs_should_be_of_keysets_only> > design decision? > > It is deliberate that s/keys works only on attributes and that you can't inline value specs. If you really need to do a wholesale coercion of all your attributes, it seems like you can do this explicitly as a pre-step before validating the map with spec and that may be the better way to go. I'm not sure what spec is buying you over just explicitly transforming the map using normal Clojure functions? You could still do individual transformations by conforming non-registered specs if desired. > Thank you, > Josh > > P.S. To confirm my understanding that there is not a way to specify > conformance inline, I attempted to create and use a spec defined like (s/keys > :req [(s/and ::foo (s/conformer ,,,))]). To my surprise, clojure.spec > used it without complaint, although the behavior of s/conform was > unaffected. Should I create a JIRA issue for this? > Right now anything that's not a keyword gets filtered out and ignored. I'd be in favor of erroring on other stuff, but not sure if that's at odds with how Rich thinks about it. So, could do an enhancement jira if you wish. > P.P.S. A previous draft of this email had detailed illustrative examples, > cut out of fear of being tiresomely long-winded. If anything I described > isn’t clear, let me know and I’ll go ahead and include the examples in the > conversation. > -- 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.
