在编译时不满足协议的实体对象

Question

https://github.com/MichaelBlume/reify-fail

`
(defprotocol Foo
(hello [this] "Says hello"))

(def bar
(reify Foo

(hello [this] "hello, world")))

(when-not (satisfies? Foo bar)
(throw (Exception. "bar doesn't satisfy Foo")))
`

注意

项目是 AOT
另一个命名空间需要这个命名空间。这个命名空间被先编译。如果没有那个命名空间，问题就消失了。

Answer 1

评论由：hiredman 提供

在检出仓库以重现此问题之后，您采取了哪些步骤？

我克隆了仓库并运行了 lein compile，但没有出现任何错误。

Answer 2

评论由：michaelblume 提供

我用 lein check 重现了此问题，但 lein compile 也失败了，所以我感到困惑。

Answer 3

评论由：michaelblume 提供

我认为先编译一个近乎空的命名空间很重要，可能不同平台的编译顺序存在差异？

Answer 4

评论由：michaelblume 提供

在我的Mac OS和Ubuntu系统下，测试版库都失败了，这两个系统都使用Java 8

Answer 5

评论由：michaelblume 提供

在Ubuntu下，我有的情况是

$ lein -v
Leiningen 2.7.1基于Java 1.8.0_151 OpenJDK 64位服务器虚拟机

Answer 6

评论由：jafingerhut_创建

在这个两个操作系统上：Ubuntu 16.04.3 Linux，macOS 10.12.6

使用这两个Leiningen版本：2.7.1，2.8.1

我相信所有实验都使用了最新的JDK 1.8版本

使用以下Clojure版本中的任何一个：1.7.0 1.8.0 1.9.0

在项目中，我使用'lein check'和'lein compile'这两个命令都会出现错误，但我必须先使用'/bin/rm -fr target'命令（或者在该目录创建之前运行它，例如，在运行'git clone'命令后立即运行）。

如果我运行命令两次，第一次命令会在目标目录中创建许多.class文件，而第二次这样的命令则不会出现错误。

Answer 7

评论由：hiredman 提供

如果我将:aot :all替换为:aot (link: com.lendup.citadel.pipeline com.lendup.citadel.providers.mocky)，我就能重现这个错误。我怀疑Leiningen可以通过在编译命名空间之间执行陈旧的命名空间检查来修复这个问题，以避免重复编译传递命名空间。

Answer 8

评论由：hiredman 提供

可能与https://github.com/technomancy/leiningen/issues/2316相关

Answer 9

评论者：ikitommi

相关： https://github.com/technomancy/leiningen/issues/2508。

Answer 10

评论者：bronsa

这是Clojure还是Lein的问题？我们能用bare clj重现这个问题吗？

Answer 11

评论者：alexmiller

我怀疑可以通过按照特定的顺序编译东西来重现它，但我没有尝试这样做。但是得出的答案可能是：按正确的顺序编译东西。

Answer 12

参考： https://clojure.atlassian.net/browse/CLJ-2303 (由michaelblume报告)