2024 状态调查!中分享你的想法。

欢迎!请查看关于页面,了解有关此工作方式的一些更多信息。

0
Spec

当我为一个正在开发的库定spec时,我遇到了s/unforms/?结合的奇怪行为。

(require '[clojure.core.specs.alpha :as cs])

(def binding-form '[a b :as c])

(def x (s/conform ::cs/seq-binding-form binding-form))
;; x => {:forms [[:local-symbol a] [:local-symbol b]], :as-form {:as :as, :as-sym c}}

(s/unform ::cs/seq-binding-form x) 
;; => (a b (:as c))

(s/valid? ::cs/seq-binding-form (s/unform ::cs/seq-binding-form x))
;; => false

这是预期行为吗?按照直觉,我本以为第一次unform会生成原始格式,并且unform的结果应该会通过(使用相同的spec)验证。

1 答案

0

被选为最佳答案
 
最佳答案

这里可能有几个问题。正则表达式格式化会解析顺序集合(特别是列表和向量),但没有方法保留原始集合类型并将格式化的结果转换为正确的类型。这是一个通用问题,在没有考虑所有方面的情况下(如果考虑了conform,unform和gen的各个方面),没有简单的解决方案。我们没有计划在spec 1中进行修订。在spec 2中,我们有了对这种类型支持,包括s/catv和s/cats,它们是特定类型的变体。

关于(:as c),我认为这是一个已知的尾随?conform的已知错误,但找到链接需要一些时间。

是啊,有一个错误报告: https://ask.clojure.org/index.php/2418/nesting-cat-inside-causes-unform-to-return-nested-result?show=2418#q2418

我没有注意到这一点。这回答了我的问题。

至于 catv,catc -- 很好的了解。我已能看出它们在宏/dsl情况下的用途。
...