评论人：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 文本：“何处不使用断言”）。这意味着 {{derive}} 在必要时应该抛出 {{IllegalArugmentException}}，而 {{fn}} 的预先和后续条件可能应该抛出 {{IllegalStateException}}，或者无论如何，通过 {{assert}} 抛出除 {{AssertionError}} 以外的其他东西。这将与 core 中使用 {{assert-args}} 而不是 {{assert}} 的许多函数相匹配，前者抛出 {{IllegalArgumentException}} 而不是 {{AssertionError}}。
这让我产生了疑问：{{assert}}（以及 * ）是否 intended to be a Clojure construct，还是一个准互操作形式？
如果是前者，那么它大致可以具有我们想要的任何语义，但是它似乎不应该抛出 {{AssertionError}}。
如果是后者，那么在 JVM 上抛出 {{AssertionError}} 是合适的，但我们需要确保可以在运行时启用和禁用断言（无需切换不同的 Clojure 构建），理想情况下使用主机定义的开/关选项（例如 {{-ea}} 及其相关选项），并且可能不使用 *。我不知道目前这是否可行或实用（我猜想这需要非微小的编译器更改）。
希望上面的讨论目前还不算过时。感谢您的耐心等待。:-)
