Yeah, my team and I were initially surprised at the lack of a built-in
option for this to s/keys, but TBH it's been an unusual use case so far,
and Alex / Beau's solutions don't seem particularly onerous despite the
repetition.
I suppose if you're using it all over the place you could write a macro
like this:
(defmacro only-keys
[& {:keys [req req-un opt opt-un] :as args}]
`(s/and (s/keys ~@(apply concat (vec args)))
(s/map-of ~(set (concat req
(map (comp keyword name) req-un)
opt
(map (comp keyword name) opt-un)))
any?)))
(please feel free to suggest a neater way!)
Cheers,
On Wednesday, 21 September 2016 18:08:25 UTC+10, David Goldfarb wrote:
>
> Nice, thanks. I had not thought to use map-of for this. And, s/merge
> certainly helps too.
>
> The only remaining issue for me is that this requires supplying the list
> of keys twice.
> AI think this case is general enough that it is worth extending the s/keys
> macro to support: (s/keys :req [::a ::b] :allow-other-keys false)
>
> Or, if is is objectionable to have a keyword default to true when not
> supplied, perhaps: (s/keys :req [::a ::b] :strict-keys true)
>
> On Tuesday, September 20, 2016 at 9:47:43 PM UTC+3, Alex Miller wrote:
>>
>> For stuff like this s/merge is probably preferable to s/and (when
>> combining map specs) - the difference being that merge does not flow
>> conformed results, will combine all failures, and that gen can work better
>> in some cases.
>>
>> (s/def ::a int?)
>> (s/def ::b string?) ;; changed for this example
>> (s/explain ::my-map {::a 1 ::b 2 ::BAD 3})
>> In: [:user/b] val: 2 fails spec: :user/b at: [:user/b] predicate: string?
>>
>> ;; vs:
>>
>> (s/def ::my-map2 (s/merge (s/keys :req [::a ::b]) (s/map-of #{::a ::b}
>> any?)))
>> (s/explain ::my-map2 {::a 1 ::b 2 ::BAD 3})
>> In: [:user/b] val: 2 fails spec: :user/b at: [:user/b] predicate: string?
>> In: [:user/BAD 0] val: :user/BAD fails spec: :user/my-map2 at: [0]
>> predicate: #{:user/a :user/b}
>>
>> ^^ Note you get *both* failures here - both bad attribute value AND the
>> invalid key vs the prior one where you only get the first failure.
>>
>>
>> On Tuesday, September 20, 2016 at 11:38:47 AM UTC-5, Beau Fabry wrote:
>>>
>>> boot.user=> (s/def ::my-map (s/and (s/keys :req [::a ::b]) (s/map-of
>>> #{::a ::b} any?)))
>>> boot.user=> (s/explain ::my-map {::a 1 ::b 2 ::BAD 3})
>>> In: [:boot.user/BAD 0] val: :boot.user/BAD fails spec: :boot.user/my-map
>>> at: [0] predicate: #{:boot.user/a :boot.user/b}
>>>
>>> Seems better
>>>
>>> On Tuesday, September 20, 2016 at 5:38:10 AM UTC-7, David Goldfarb wrote:
>>>>
>>>> In clojure.spec, how can I declare a map that accepts only certain
>>>> keys?
>>>>
>>>> *{::a 1 ::b 2 ::BAD 3}* does conform to *(s/keys :req :req [::a ::b])*,
>>>> but I want a spec that will be bothered by ::BAD or any other undeclared
>>>> key.
>>>>
>>>> My use case: I am introducing spec to some legacy code, and I want to
>>>> be warned if I have failed to specify some elements that may appear in my
>>>> map.
>>>>
>>>>
>>>> Question 2:
>>>>
>>>> So, assuming that this is not possible currently, I brute-forced it
>>>> with:
>>>>
>>>> *(defn- key-checker [valid-keys]*
>>>> * (fn [map-to-check]*
>>>> * (empty? (clojure.set/difference (into #{} (keys map-to-check))
>>>> valid-keys))))*
>>>>
>>>> *(s/def ::my-map (s/and (s/keys :req [::a ::b]) (key-checker #{::a
>>>> ::b})))*
>>>>
>>>>
>>>> Ignoring the ugly, and easily fixable, smell of the duplicated set of
>>>> keys, this has a bigger problem:
>>>>
>>>> If the predicate fails, the error that assert gives me is *"{... big
>>>> ugly map ...} fails predicate: (key-checker #{::a ::b})"* with no easy
>>>> way for the viewer to see which key failed. Can I somehow hook into the
>>>> explain mechanism to give a more useful message?
>>>>
>>>
--
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.
