评论者：cemerick
SS关于这个方法对Maven没有问题。此外，构建可以很容易地配置以为总是发出两个jar，一个"正常"，一个"debug"。
我建议，尽管 {{clojure.debug}} 可能会有广泛的影响，但还应该提供额外的属性，以便对将来可能可用的每个额外的"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}}应该抛出{{IllegalArgumentException}}，fn的前置和后置条件可能抛出{{IllegalStateException}} - 或者在任何情况下，通过{{assert}}抛出{{AssertionError}}之外的异常。这将与大多数使用{{assert-args}}而不是{{assert}}的核心中的函数更匹配，前者抛出{{IllegalArgumentException}}而不是{{AssertionError}}。
这让我产生了疑问：{{assert}}（和* }) 是一个Clojure构造，还是一个准互操作形式？
如果前者，那么它的大致语义可以是我们想要的任意一种，但是看起来它不应该是抛出{{AssertionError}}。
如果后者，那么在JVM上使用{{AssertionError}}是合适的，但我们需要注意assertions可以在运行时打开或关闭（而无需在不同构建的Clojure之间切换），理想情况下使用宿主定义的开关（例如，{{-ea}}及其相关开关），很可能不是像*这样的东西。我不知道目前这是否可能或实用（我推测这可能需要非微不足道的编译器更改）。
希望到目前为止以上内容还没有成为过眼云烟。提前感谢您的耐心。:-)
