On Tuesday, May 9, 2017 at 6:21:29 AM UTC-5, Dave Tenny wrote: > > My issues aren't about qualified or unqualified keys (and the APIs > generally need to accept unqualified keys - I do use qualified keys in > various contexts, just not this post where the topic is macros vs. > non-macro forms). >
spec pushes you towards qualified keys for good reasons (see Rich's original rationale), so I don't expect that we'll be adding more support for unqualified keys. The support that is there is intended as a bridge towards qualified keys. > s/merge is a good point about composition. However often all I really > want to do is take some list of, say, keywords, acceptable in a map or > collection that is a parameter, and 'disj' one keyword from it for another > spec because that particular keyword isn't valid or supported for an > interface in question. > I have found that when I'm seeing this a lot, either the code is not modeling the domain well by not factoring common attributes OR my domain structures are actually very dynamic and have many optional attributes that can occur in any combination. In the former case, I can usually step back and refactor the code so that attributes that are always grouped together have their own unit and functions. In the latter case, the key is often to spec less. Instead of trying to identify every attribute on every function input and output, just create a single map spec with all of the optional attributes. You can then constrain it further if needed by doing (s/merge ::common (s/keys :req [::foo ::bar])) if needed. Or another approach is to just use (s/keys) to validate all the attributes that happen to be in a map flowing through a function. This is exactly the use case that spec makes possible that few other validation approaches can handle well (the case of checking arbitrary attributes flowing through a system) and its enabled by the use of qualified names with global semantics. At the end of the day, I feel I'm often forced to cut and paste too many > similar but different lists into various specs (fdef in particular). The > ability to construct specs without macros might be useful. > We don't have them available yet, but we will have specs for spec forms (see CLJ-2112). With specs for spec forms, you can programmatically transform or construct maps in this way. With spec forms, you can start from a spec, s/conform to data, manipulate that data in any way you like, then s/unform back to a spec. You can also start in the middle and construct the conformed data version of a spec and s/unform to the list form. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
