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

欢迎!请查看关于页面以了解更多关于该功能的信息。

+1
Spec
由于解构规范是用 `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 调用 clojure.core/let 时未遵守规范
在: [0 0] val: #:user{:keys [a]} 违规 spec: :clojure.core.specs/local-name 在: [:args :bindings :binding :sym] 判定器: simple-symbol?
在: [0 0 0] val: ([:user/keys [a]]) 违规 spec: :clojure.core.specs/seq-binding-form 在: [:args :bindings :binding :seq] 判定器: (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))), 多余输入
在: [0 0 :user/keys] val: [a] 违规 spec: :user/keys 在: [:args :bindings :binding :map :user/keys] 判定器: nil?
:clojure.spec/args ([#:user{:keys [a]} #:user{:a 1}] a)
  clojure.core/ex-info (core.clj:4725)


这感觉像是实现细节泄漏。

4 个答案

0

评论人:bbloom

我也遇到了这个问题。我只是想说说,我希望看到修复,但我不太确定提出的解决方案。或者至少,名字 "closed?" 似乎暗示了不可扩展的映射,实际上这个标志更多或更少地意味着 "不是参与全局键系统的映射",对于这个我没有更好的名字建议。

0

评论人:alexmiller

提出的补丁是不可行的。我有一些想法来解决这个问题,但还没开始动手。

0

评论人:alexmiller

由于我们不会走这个方向,已从工单中移除提案和补丁。此处记录以供参考。

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

在此补丁之后,上述示例运行良好,并且未将 :closed? 设置为 true 的 s/keys 使用将根据当前行为验证 ::keys

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

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