评论者为：cemerick
SS关于这种方法不会对Maven造成任何问题的说法是正确的。此外，构建可以很容易地设置以始终输出两个jar文件，一个是“正常”的，另一个是“调试”。
建议，虽然{{clojure.debug}}可能具有广泛的影响，但应该有额外的属性可用，以便提供对可能在未来成为可用的每个额外的“调试”相关参数化的细粒度控制。
我想提出一些可能相关的担忧（在考虑上述上下文中的断言之后），其中一些或全部可能只是我对各个领域的理解不足的结果。
查看{{assert}}在{{core.clj}}中的使用位置（据我所知只有两个地方：验证{{derive}}的参数和检查{{fn}}的前置和后置条件），这似乎是不明智的将其默认为{{false}}。即非{{Named}}值能够进入层次结构，前置和后置条件将被简单地忽略。
根据我的理解，断言（此处指JVM结构，Clojure重新使用{{AssertionError}}），不应用于验证公共API函数的参数，或用于验证函数正常操作的任何方面（即(link: http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#usage文字：“不应使用断言的地方”))。这意味着当需要时，{{derive}}应该抛出{{IllegalArugmentException}}，而fn的前置和后置条件可能会抛出{{IllegalStateException}}--或者，在任何情况下，通过{{assert}}抛出不是{{AssertionError}}的其他东西。这将与在核心中使用{{assert-args}}而不是{{assert}}的大多数函数更匹配，前者抛出{{IllegalArgumentException}}而不是{{AssertionError}}。
这使我产生了疑问：{{assert}}（和* }）是打算成为Clojure结构，还是一个准交互形式？
如果是前者，那么它的大致语义可以是任何我们想要的，但似乎它不应该抛出 {{AssertionError}}。
如果是后者，那么在 JVM 上使用 {{AssertionError}} 是合适的，但我们需要注意，断言可以在运行时启用和禁用（而无需切换不同的 Clojure 构建），理想情况下使用宿主定义的开关（例如 {{-ea}} 和其他），可能不会是任何类似 * 的选项。我不知道这一点是否可行或实用（我推测这可能需要非平凡的字节码编译器更改）。
希望以上的讨论还没有过时。提前感谢您的耐心。;-)
