评论人：cemerick
SS关于这个方法对 Maven 没有问题。此外，构建可以轻松设置以始终发出两个jar包，一个“常规”的，一个“调试”的。
我建议，虽然 clojure.debug 可能会有广泛的影响，但应该提供额外的属性，以便对可能在未来提供的每个额外的“调试”相关的参数化进行细粒度控制。
我想提出一些可能相关的关注点（在上述上下文中思考了一段时间之后），其中一些或所有这些可能只是我对各个领域缺乏理解的简单结果。
查看在 core.clj 中 {{assert}} 的使用位置（据我所知只有两个地方：验证 {{derive}} 的参数和检查 {{fn}} 中的预条件和后条件），似乎不合理默认使其为 {{false}}。即非 {{Named}} 值将能够进入层次结构，而且预条件和后条件将简单地被忽略。
我理解断言（这里指 JVM 构造，Clojure 重新使用 {{AssertionError}}），不应该用于验证公共API函数的参数，也不应该用于验证函数正常操作的任何方面（即（link: http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#usage text: "where not to use assertions"））。这意味着当需要时，{{derive}} 应该抛出 {{IllegalArgumentException}}，而 fn 的预条件和后条件可能应该抛出 {{IllegalStateException}} — 或者，无论如何，通过 {{assert}} 抛出其他不是 {{AssertionError}} 的东西。这将更好地与 core 中的大多数函数使用 {{assert-args}} 而不是 {{assert}} 匹配，前者抛出 {{IllegalArgumentException}} 而不是 {{AssertionError}}。
这导致我提出问题：{{assert}}（和 * }）是否是 Clojure 构造，还是伪互操作形式？
如果是前者，则可以大致有我们想要的任何语义，但是似乎它不应该抛出 {{AssertionError}}。
如果是后者，那么在JVM上抛出{{AssertionError}}是合适的，但我们需要注意，断言可以在运行时启用和禁用（无需切换Clojure的不同版本），理想情况下使用宿主定义的开关（例如{{-ea}}等）以及不太可能像*这样的东西。我不知道这一点是否可行或实用（我认为这需要非琐碎的编译器更改）。
希望上面的内容现在还不是过去式。提前感谢您的耐心。;-)
