评论者：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}}及其朋友），并且可能不应该是类似 * 这样的东西。我不知道现在这是否可能或实用（我猜想这需要非平凡的编译器更改）。
希望上述内容到这个时候还没有过时。提前感谢您的耐心。 :-)
