clojure.lang 真的只是实现细节吗？
Is clojure.lang really just implementation details?
在 Clojure 中，一些任务（例如实例化一个 PersistentQueue or using deftype to implement a custom data type that is compatible with the clojure.core functions) require knowledge of the classes and/or interfaces in clojure.lang。
然而，根据clojure.lang/package.html：
The only class considered part of the public API is clojure.lang.IFn. All other classes should be considered implementation details.
这些说法是错误的还是过时的？如果是这样，将来是否有纠正它们的计划？如果没有，是否有更好的方法来执行上述任务，或者根本不应该在惯用的 Clojure 代码中完成这些任务？
亚历克斯·米勒 (Alex Miller) 过去曾 commented 讨论过这个问题（尽管整个话题值得一读）：
I'd say there is a range of "public"-ness to the internals of Clojure.
- The new Clojure API (clojure.java.api.Clojure) is an official public API for external callers of Clojure. This API basically consists of ways to resolve vars and invoke functions.
- For Clojure users in Clojure, pretty much any var that's public and has a docstring, and shows up in the api docs can be considered public API.
- Clojure vars that are private or have no docstring (such that the var is omitted from public api docs) are likely places to tread very carefully.
- The Clojure internal Java interfaces [
clojure.lang] are certainly intended to allow library builders to create useful stuff that plays in the Clojure world. I do not know that anyone has ever said that they are "public", but I certainly think that any change to a core interface likely to break external users would be considered very carefully.
- The Clojure internal Java classes [
clojure.lang] should in most cases be considered private and subject to change without notice. There are grey areas even there.
In general, we do not place a high value on encapsulation or hiding internals. In most cases, the internals are left available if they might be useful to an advanced user doing interesting things, with the caveat that the weirder things you do, the more likely you are to be accidentally broken in a future release.
在 Clojure 中，一些任务（例如实例化一个 PersistentQueue or using deftype to implement a custom data type that is compatible with the clojure.core functions) require knowledge of the classes and/or interfaces in clojure.lang。
然而，根据clojure.lang/package.html：
The only class considered part of the public API is
clojure.lang.IFn. All other classes should be considered implementation details.
这些说法是错误的还是过时的？如果是这样，将来是否有纠正它们的计划？如果没有，是否有更好的方法来执行上述任务，或者根本不应该在惯用的 Clojure 代码中完成这些任务？
亚历克斯·米勒 (Alex Miller) 过去曾 commented 讨论过这个问题（尽管整个话题值得一读）：
I'd say there is a range of "public"-ness to the internals of Clojure.
- The new Clojure API (clojure.java.api.Clojure) is an official public API for external callers of Clojure. This API basically consists of ways to resolve vars and invoke functions.
- For Clojure users in Clojure, pretty much any var that's public and has a docstring, and shows up in the api docs can be considered public API.
- Clojure vars that are private or have no docstring (such that the var is omitted from public api docs) are likely places to tread very carefully.
- The Clojure internal Java interfaces [
clojure.lang] are certainly intended to allow library builders to create useful stuff that plays in the Clojure world. I do not know that anyone has ever said that they are "public", but I certainly think that any change to a core interface likely to break external users would be considered very carefully.- The Clojure internal Java classes [
clojure.lang] should in most cases be considered private and subject to change without notice. There are grey areas even there.In general, we do not place a high value on encapsulation or hiding internals. In most cases, the internals are left available if they might be useful to an advanced user doing interesting things, with the caveat that the weirder things you do, the more likely you are to be accidentally broken in a future release.