评论由：cemerick
SS关于这个方法不会对Maven产生任何问题的说法是正确的。此外，构建可以轻松设置以始终生成两个jar文件，即“正常”的和一个“调试”的。
我建议，虽然{{clojure.debug}}可能有广泛的影响，但应该有额外的属性来提供对可能在未来提供的每个额外的“调试”相关参数化的精细控制。
我想要提出一些可能的相关担忧（现在在上面关于断言的上下文中思考了一下），其中一些或全部可能只是我对各领域缺乏理解的结果。
查看在哪里使用{{assert}}在{{core.clj}}（据我所知只有两个地方：验证{{derive}}的参数以及在{{fn}}中检查前置和后置条件），似乎不合理将其设置为{{false}}。即非{{Named}}值能够进入层次结构，前置和后置条件将简单地被忽略。
我的理解是，断言（这里指的是JVM结构，Clojure复用了{{AssertionError}}）不应该用于验证公开API函数的参数，也不应用于验证函数正常操作中的任何方面（即（链接：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}}等），而不是类似*的东西。我不知道这一点是否可能或实用（我推测这需要非微不足道的编译器更改）。
希望上面的内容不是没有意义。在此先感谢您的耐心。:-)
