评论者：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}}应该抛出{{IllegalArgumentException}}，而fn前后的条件可能应该抛出{{IllegalStateException}} -- 或者，无论如何，应该通过{{assert}}抛出{{AssertionError}}以外的东西。这将与大多数使用{{assert-args}}而不是{{assert}}的核心函数相吻合，前者抛出{{IllegalArgumentException}}而不是{{AssertionError}}。
这让我想到一个问题：{{assert}}（以及*）是否是Clojure构造，或者是一种准跨交形式？
如果是前者，那么它大体上可以具有我们想要的任何语义，但是这似乎意味着它不应该抛出{{AssertionError}}。
如果是后者，那么在JVM上使用{{AssertionError}}是合适的，但是我们需要注意，断言可以在运行时启用和禁用（而无需在不同版本的Clojure之间切换），理想情况下使用宿主定义的开关（例如{{-ea}}及其相关），而不太可能是类似*的东西。我不知道这目前是否可行或实用（我猜测这需要非平凡的编译器更改）。
希望以上的说明不会成为过去式。先谢谢您的耐心。 ;-)
