评论者：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}} 及相关选项），而很可能不是像 * 这样的。我不知道目前这是否可行或实用（我猜测这需要相当大的编译器更改）。
希望上述内容不是目前的过眼云烟。提前感谢您的耐心。:-)
