在defprotocol和deftype宏中允许预先和后续条件

Question

fn特殊形式和defn宏允许预先和后续条件。如果能将这些条件也用于defprotocol和deftype宏的方法声明中那就更好了。

目前我使用extend函数作为解决方案，在其中可以通过关键字-名称和fn特殊形式的映射指定方法。

Answer 1

评论者：michael-drogalis

我认为使用{{:pre}}和{{:post}}不是一个好主意。断言处理是两部分游戏。该机制需要考虑到检测和反应，而后者是缺失的。

这不是一个完美的解决方案，因为它的语法略显冗长，但使用（链接：https://github.com/MichaelDrogalis/dire 文本：Dire）可能比使用extend更有效。此外，您还会得到{{:pre}}和{{:post}}中缺失的“反应”功能。

协议预先条件的示例： https://gist.github.com/4471276

Answer 2

评论者：akiel

@Michael，我已经阅读了你的（链接：https://gist.github.com/4471276 文本：gist）以及（链接：https://github.com/MichaelDrogalis/dire 文本：Dire）的README。我认为Erlang的监督概念有其用武之地，但我不太喜欢用于预先和后续条件。对我来说，这样的条件有两个目的

1. 他们应该记录代码和
2. 他们应该快速失败，以便尽早发现故障。

为了支持我的第一个观点，你的前提条件和后置条件与实际函数定义的词汇距离也太远了。关于第二个观点：我认为在违规的情况下，程序应该直接崩溃。也许可以用你的异常监督器包裹程序的一部分来处理AssertionError。但我认为，处理单个函数的前提条件和后置条件违规不是一件好事。

Answer 3

评论者：michael-drogalis

@Alexander 的确，你的观点是正确的。Dire 的含义正是你描述的那样。与应用程序逻辑词汇上分离，并有机会从崩溃中恢复。无论如何，这是我快速帮助你解决需求的最佳尝试。 :)

Answer 4

参考： https://clojure.atlassian.net/browse/CLJ-1141 （由 akiel 报告）

Answer 5

我不知道这难道不是由于关联接口可以在 Java 中实现而无法实现的原因吗。任何这样的实现都不会包括前提条件和后置条件，这可能会破坏假设。

Comments

这可以在 `defrecord` 实现`上完成。它依赖于 `maybe-destructure`，根据类似 `clojure/core.clj` 中 `fn` 重新定义的代码路径。可以简单地复制粘贴。

我怀疑这将会工作得很好，但我知道我还没有考虑到边缘情况，也许有一些速度等的成本收益已经被考虑在内。@alexmiller，有什么看法吗？