评论由：cemerick
SS 关于此方法不会对Maven造成任何问题的说法是正确的。此外，构建可以很容易地设置为始终生成两个jar文件，一个是“正常”的，一个是“调试”的。
我建议，虽然{{clojure.debug}}可能具有广泛的影响，但也应提供额外的属性，以提供对将来可能出现的每个额外的“调试”相关参数化进行细粒度控制的手段。
我想提出一些可能有些不相关的问题（在那段关于断言的思考之后），其中一些或全部可能是由于我在各个领域的理解不足造成的。
从where {{assert}} is used in {{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}}及其同类），很可能不会是 * 之类的任何东西。我不知道这目前是否可行或实用（我推测这可能需要非平凡的编译器更改）。
希望上述内容目前还没有成为过去式。提前感谢您的包容。;-)
