2024年Clojure状态调查!中分享您的想法。

欢迎!请参阅关于页面以了解更多操作信息。

0
Spec
重现


(require '[clojure.spec.alpha :as s]
(s/def :foo/user-map (s/map-of string? int?))
(s/explain-data :foo/user-map {"hi" "foo"})
;; 实际值
;; #:cljs.spec.alpha{:problems
;;                 ({:path [1],
;;                   :pred int?,
;;                   :val "foo",
;;                   :via [:foo/user-map],
;;                   :in ["hi" 1]})}
;; 预期:`:in`值应该是 ["hi"] ?
(s/explain-data :foo/user-map {:hi 2})
;; 实际值
;; #:cljs.spec.alpha{:problems
;;                 ({:path [0],
;;                   :pred string?,
;;                   :val :hi,
;;                   :via [:foo/user-map],
;;                   :in [:hi 0]})}
;; 预期:我不确定,因为路径不能“指向”键


动机:给一些顶层数据(在这种情况下,`{"hi" "foo"}`)和一个`:in`路径,我希望能找到有问题的数据(在这种情况下,"foo")。

在这种情况下,如果映射的值不符合,`:in`路径与像`get-in`这样的函数不相容,但它可能是。

在这种情况下,如果映射的键不符合,就无法使用`get-in`“指向”键,所以我不确定正确的解决方案是什么。

我不知道与`get-in`的兼容性是否是必需的:如果规范提供了一个使用“规范”路径(即可以指向键的路径)完成相同任务的函数,那就没问题。

3 条回答

0

评论者:jpmonettas

我认为,与兼容性相比,匹配:clojure.spec.alpha/problems在uai:clojure.spec.alpha/value中的方式,与导致问题的事件规格无关,更为重要。
对于此,我认为知道问题是在键还是值上很重要。

目前s/map-of考虑到了map-entry vec的路径,因此0将是键,1将是值。

我正在尝试实现的毛病是in是s/keys,它只报告键。

所以当你看到(link: ::k 1)中的问题时,你不知道这是在map值上的问题,还是值是一个序列,而问题在于该序列中位置1的值。

0

评论者:bbrinck

我同意上面的说法,并在使用in路径具有更多经验后想要进一步阐述。

AUI,clojure.spec不打算提供易于阅读的错误信息。相反,它旨在提供一个坚实的平台,以便库可以以各种方式呈现错误。

在我的经验中,尝试以不同的方式呈现错误(Expound),我可以报告在尝试解释in路径时遇到的最大的挑战之一。

有两大挑战特别令人难以刹车:在map-of规格中指示"键"或"值"失败的整数索引,以及在coll-of规格中指示"键/值"向量位置的整数索引。

我可能只是没有理解' SIG_PATH 工作方式,但据我所知,这是其他库作者的困惑之源。[链接](https://groups.google.com/forum/#!topic/clojure/ppnWBJhz-R4)。此外,由于此路径在使用explain时显示给用户,因此不含有歧义的路径将有助于所有规格用户更好地理解他们的错误。

是否可以创建无歧义的路径,而不需要读者了解路径的使用方式?如上所述,路径[:key 1]只能通过了解有关失败数据结构的信息来区分。这可能需要用自定义记录替换整数索引。这可能会降低简洁性和可读性,但这可能可以通过新的读者宏来缓解。

0
参考资料:[链接](https://clojure.atlassian.net/browse/CLJ-2192)(由bbrinck reporting)
...