当数据无法遵守`map-of`规范时，`:in`路径不会指向无效的（内部）值

Question

重现


(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`是否是必需的：如果规范提供了一个具有“规范”路径的函数来完成相同的事情（即可以指向键的路径），那么这将很好。

Answer 1

评论由: jpmonettas 完成

我认为，与兼容性相比，更重要的是一种匹配：clojure.spec.alpha/problems 内部的方法，它不依赖于导致问题的规范命名空间。
在这方面，我认为了解问题是否在键或值上是重要的。

目前 s/map-of 会根据 map-entry 向量报告路径，因此 0 将是键，1 将是值。

我所尝试实施的问题在于：in 是 s/keys，它只报告键。

因此，当你在 (link: ::k 1) 中看到问题时，你不知道它是地图值的问题，还是值是一个序列，而问题是在该序列的 pos 1 位置。

Answer 2

评论由: bbrinck 完成

我同意上面的说法，并且在更多使用 {{in}} 路径的经验之后，我想进一步拓展。

据我所知，clojure.spec 并非旨在提供易于阅读的错误消息，而是旨在提供一个坚实的基础，以便库可以以多种方式展示错误。

在我尝试以不同的方式（Expound）展示错误的经验中，我可以报告说，尝试理解 {{in}} 路径是最大的挑战之一。

特别是有两种情况具有挑战性：在 {{map-of}} 规范中指示 "键" 或 "值" 失败的整数索引，以及在 {{coll-of}} 规范中指示 "键/值" 向量中的位置的整数索引。

我可能只是未能理解 'in' 路径的工作方式，但据我所知，这是其他库作者困惑的来源。 https://groups.google.com/forum/#!topic/clojure/ppnWBJhz-R4 。此外，由于此路径在调用 {{explain}} 时会向用户展示，因此一个不太模糊的路径将有助于所有规范用户更好地理解他们的错误。

是否有可能创建一个不模糊的路径，不需要读者知道如何使用路径？如上所述，路径 {{[:key 1]}} 只能通过了解失败的数据结构来区分。这可能需要用自定义记录替换整数索引。这可能会减少简洁性和可读性，但可能会通过新的阅读器宏来缓解这种影响。

Answer 3

参考： https://clojure.atlassian.net/browse/CLJ-2192 （由 bbrinck 报告）