:or 默认值应参照嵌套作用域在map解构中

Question

https://groups.google.com/d/msg/clojure/6kOhpPOpHWM/ITjWwQFS_VQJ

Michael Blume 注意到 :or 默认值可能依赖于其他键的值，请参阅 https://groups.google.com/d/msg/clojure/6kOhpPOpHWM/ITjWwQFS_VQJ




Michael Blume 注意到 :or 默认值可能依赖于其他键的值，请参阅 https://groups.google.com/d/msg/clojure/6kOhpPOpHWM/ITjWwQFS_VQJ
Michael 的 Gist https://gist.github.com/MichaelBlume/4891dafdd31f0dcbc727 展示了一个涉及到 :keys 和 :or 的关联表，根据 :keys 中的符号顺序编译或不编译的情况。通过调整这个情况，可以得到总是编译但根据 :keys 产生不同结果的表达式




我相信最自然的解决方案是要求在嵌套作用域中评估 :or 默认值，在该作用域中没有出现任何解构引入的局部变量。这种方法在 0001 补丁中被采用。
请求
jira

请登录或注册来添加评论。


请登录或

• 请求
• jira

请登录或login or

Answer 1

评论者：michaelblume

我怀疑这是正确的事情，但我认为重要的是要注意，这将破坏现有的代码 https://github.com/ngrunwald/ring-middleware-format/blob/master/src/ring/middleware/format_params.clj#L214

Answer 2

评论者：michaelblume

关于我之前的评论更新 -- 环境中间件-参数已更新，不再依赖于这种行为。我认为我们绝对应该合并此补丁，以免其他人也依赖它。

Answer 3

评论人：mpenet

由于这涉及 :or 键的评估，可能需要检查这将对http://dev.clojure.org/jira/browse/CLJ-1676有何影响。

Answer 4

评论人：stu

这是一个行为变更，文档并未承诺此行为，现有代码可能依赖于当前的行为。

Answer 5

评论人：jafingerhut

这不是一种情况，即现有代码之所以能工作，只是由于无序映射的序列顺序的巧合吗？如果是这样，那么任何依赖于现有行为的代码在Clojure映射的序列顺序从Clojure 1.5.1到Clojure 1.6.0，再到1.6.0到1.7.0发生变化时，有时会出错，有时不会出吗？

Answer 6

评论者：michaelblume

是的，确实如此，我因那些变化看到了现有代码出错，这就是导致此票据的讨论。

Answer 7

评论者：michaelblume

更新此补丁

Answer 8

_评论人：michalmarczyk_

@Stuart

为了证实上述说法，以下是在Clojure 1.6 REPL和Clojure 1.7 REPL中评估的相同代码片段，两个REPL均是新启动的，并得到不同的结果


Clojure 1.6.0
(let [foo 1 bar 2
请求
jira
  [foo bar])
[3 2]

Clojure 1.7.0
(let [foo 1 bar 2
请求
jira
  [foo bar])
[3 4]


文档中并未承诺没有这样的意外交互会发生，但如上所示，任何依赖1.6行为的现有代码在1.7中已被破坏。指定某些行为并在未来保持一致将防止出现此类意外。

我认为当前行为在某种程度上是“随机的”，因为没有原则上的原因可以预期它——因此我提出了一个提案，在修补程序中实现{{:or}}默认值引用封装作用域。

Answer 9

评论者：michaelblume

修补程序更新已应用于master

Answer 10

参考资料：https://clojure.atlassian.net/browse/CLJ-1613 （由michalmarczyk报告）