A use case that comes to mind is a system/library that specifies the
structure of some inputs/outputs, but lets users/consumers (optionally)
specify further validation of the leaves. I suppose that would be possible
with (s/def ::foo any?) but you'd have to be a bit more careful about load
order. The other use case (which is mine) is I'm just lazy and only want to
write out broad strokes specs sometimes without getting into the nitty
gritty.
If s/keys were to validate that the keys it's provided have specs it would
have to do it at validation time, so you wouldn't get the error until
something was actually validated against that key spec. Trying to do it at
definition time would break recursive specs.
As one of the (apparently pretty uncommon) users who actually does happily
define s/keys specs without correspondingly speccing the leaves as an
"incrementally lock down/validate" approach, I wouldn't be too upset if I
lost that ability and it started throwing an error. I mean it throws an
error if I go to generate it anyway.
On Friday, October 6, 2017 at 8:58:38 AM UTC-7, Leon Grapenthin wrote:
>
> Thanks, Beau.
>
> I am still interested why this default behavior has been chosen. It
> doesn't seem like a reasonable trade-off at this point.
>
> It enables me to say: "The map must have this key", without specifying how
> the data mapped to it will look like.
>
> If I ever wanted to do that, I could as well spec that key with "any?".
>
> What are other benefits? They must justify the expense of likely runtime
> errors.
>
>
> On Friday, October 6, 2017 at 5:34:16 PM UTC+2, Beau Fabry wrote:
>>
>> Leon, perhaps you could add this code to your test suite?
>>
>> boot.user=> (let [kws (atom #{})]
>> #_=> (clojure.walk/postwalk (fn [x] (when (qualified-keyword? x)
>> (swap! kws conj x)) x) (map s/form (vals (s/registry))))
>> (clojure.set/difference @kws (set (keys (s/registry))))
>> #_=> )
>> #{:clojure.spec.alpha/v :clojure.spec.alpha/k}
>> boot.user=>
>>
>> On Friday, October 6, 2017 at 5:56:29 AM UTC-7, Leon Grapenthin wrote:
>>>
>>> Open maps/specs are fine.
>>>
>>> s/keys supporting unregistered specs are not.
>>>
>>> At least to me. I just fixed two more bugs in production that were would
>>> not have happened.
>>>
>>> What are the supposed benefits of this feature?
>>>
>>> I can only infer "being able to require keys without their spec being
>>> known" which is a usecase I had exactly 0.00% of the time so far.
>>>
>>> Anything I have missed?
>>>
>>> Kind regards,
>>> Leon.
>>>
>>>
>>> On Wednesday, October 4, 2017 at 7:05:29 PM UTC+2, Beau Fabry wrote:
>>>>
>>>> Seems like that's the reasonable place to check it, otherwise you're
>>>> forced into an ordering for your specs and cannot write recursive strict
>>>> map specs.
>>>>
>>>> On Wednesday, October 4, 2017 at 8:59:59 AM UTC-7, Yuri Govorushchenko
>>>> wrote:
>>>>>
>>>>> Thanks. This approach is also different from the macro because it will
>>>>> check specs existence at the validation time, not at the s/def call.
>>>>>
>>>>> On Wednesday, October 4, 2017 at 4:18:16 PM UTC+3, Moritz Ulrich wrote:
>>>>>>
>>>>>> Yuri Govorushchenko <yuri....@gmail.com> writes:
>>>>>>
>>>>>> > Thank you the pointers! So far I ended up with writing a small
>>>>>> `map` macro
>>>>>> > which is similar to `s/keys` but checks that keys are already in
>>>>>> the
>>>>>> > registry:
>>>>>> https://gist.github.com/metametadata/5f600e20e0e9b0ce6bce146c6db429e2
>>>>>>
>>>>>> Note that you can simply combine a custom predicate and `s/keys` in
>>>>>> clojure.spec to verify that all keys in a given map have a underlying
>>>>>> spec:
>>>>>>
>>>>>> ```
>>>>>> (s/def ::whatever (s/and (s/keys ...)
>>>>>> #(every? keyword? (keys %))
>>>>>> #(every? (comp boolean s/get-spec) (keys %))
>>>>>> )
>>>>>> ```
>>>>>>
>>>>>
--
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.
