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

欢迎!请参阅关于页面以了解更多关于此如何工作的信息。

+1
规范
鉴于解构规范是用`s/keys`实现的,所以目前为`::keys`或`::strs`定义规范是有问题的,因为它将与尝试使用`::keys`进行解构冲突。

user=> (require '[clojure.spec :as s])
nil
user=> (s/def ::keys nil?)
:user/keys
user=> (let [{::keys [a]} {::a 1}] a)
ExceptionInfo Call to clojure.core/let did not conform to spec
In: [0 0] val: #:user{:keys [a]} fails spec: :clojure.core.specs/local-name at: [:args :bindings :binding :sym] predicate: simple-symbol?
In: [0 0 0] val: ([:user/keys [a]]) fails spec: :clojure.core.specs/seq-binding-form at: [:args :bindings :binding :seq] predicate: (cat :elems (* :clojure.core.specs/binding-form) :rest (? (cat :amp #{(quote &)} :form :clojure.core.specs/binding-form)) :as (? (cat :as #{:as} :sym :clojure.core.specs/local-name))),  Extra input
In: [0 0 :user/keys] val: [a] fails spec: :user/keys at: [:args :bindings :binding :map :user/keys] predicate: nil?
:clojure.spec/args  ([#:user{:keys [a]} #:user{:a 1}] a)
  clojure.core/ex-info (core.clj:4725)


这似乎是一个实现细节泄露。

4 答案

0

评论者:bbloom

我也遇到了这个问题。只是想说我希望看到修复,但我并不是很确定关于所提出的解决方案。或者至少,名称“closed?”似乎暗示了一个不可扩展的映射,但实际上标志更像是“不参与全局keys系统的映射”,我没有更好的名称建议。

0

评论者:alexmiller

所提出的补丁无法开始。我对解决这个问题有一些想法,但还没有着手工作。

0

评论者:alexmiller

由于不会走这条路,已从缺陷中移除提案和补丁。此处记录以供参考。

"附加的补丁通过向 s/keys 添加 :closed? 选项并用于解构规范,实现了对该问题的解决方案。如果使用带有 :closed? 设置为 true 的 s/keys,则 conform 只会验证声明的规范,而不是 s/keys 的默认行为,即验证所有具有现有规范的命名空间关键字。

此补丁后,上述示例运行正常,且未将 :closed? 设置为 true 的 s/keys 将按照当前行为与 ::keys 进行验证。

补丁: close-destructuring-keys-specs.diff"

0
参考:https://clojure.atlassian.net/browse/CLJ-2074(由bronsa报告)
...