评论者：cemerick
SS 关于这一点，这种方法对 Maven 没有任何问题。此外，构建可以轻松设置以始终发出两个 JAR，一个是“普通”，另一个是“调试”。
我建议，虽然 {{clojure.debug}} 可能会有广泛的影响，但还应提供额外的属性，以提供对每个未来可能出现的附加“调试”相关参数的更精细控制。
我想提出一些可能相关的担忧（在思考了上面的断言后），其中一些或全部可能只是我对自己在各个领域的理解不足的结果。
查看在 {{core.clj}} 中如何使用 {{assert}}（据我所知，只有两个地方：验证 {{derive}} 的参数和在 {{fn}} 中检查前条件和后条件），似乎使其默认为 {{false}} 是不明智的。也就是说，非 {{Named}} 值能够进入层次结构，前条件和后条件将会被忽略。
我的理解是，断言（在这里指 JVM 构造，其中 Clojure 重新使用 {{AssertionError}}）不应用于验证公共 API 函数的参数，或用于验证函数正常操作的任何方面（即（链接：http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#usage text: "where not to use assertions"）)。这意味着当需要时，{{derive}} 应该抛出 {{IllegalArugmentException}}，fn 的前和后条件可能应该抛出 {{IllegalStateException}} -- 或者，无论如何，通过 {{assert}} 抛出其他非 {{AssertionError}}。
这引导我提出一个问题：{{assert}}（和 * }) 是一个 Clojure 构造，还是一个准互操作形式？
如果是前者，那么它可以大致拥有我们想要的任何语义，但似乎不应该抛出 {{AssertionError}}。
如果是后一种情况，那么在JVM上使用{{AssertionError}}是合适的，但此时我们需要注意，断言可以在运行时启用和禁用（无需切换不同的Clojure构建版本），理想情况下使用宿主定义的开关（例如{{-ea}}和其他相关选项），而不是类似*的任何东西。我不知道这目前是否可行或实用（我认为这需要进行非微不足道的编译器更改）。
希望上述内容目前还不是过时的话题。提前感谢您的耐心。;-)
