clojure.lang真的只是实现细节吗? [英] Is clojure.lang really just implementation details?

查看:72
本文介绍了clojure.lang真的只是实现细节吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在Clojure中,一些任务(例如实例化 PersistentQueue 或使用 deftype 来实现与<$ c兼容的自定义数据类型$ c> clojure.core 函数)需要了解 clojure.lang

In Clojure, some tasks (such as instantiating a 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

However, according to clojure.lang/package.html:


唯一被认为是公共API一部分的类是 clojure.lang.IFn 。所有其他类都应视为实现细节。

The only class considered part of the public API is clojure.lang.IFn. All other classes should be considered implementation details.

这些语句是否正确或过时?如果是这样,将来是否有计划纠正它们?如果不是,是否有更优选的方法来执行上述任务,还是根本不应该用惯用的Clojure代码完成这些任务?

Are these statements incorrect or outdated? If so, are there plans to correct them in the future? If not, is there a more preferred way to perform the tasks mentioned above, or should they simply not be done at all in idiomatic Clojure code?

推荐答案

亚历克斯·米勒(Alex Miller)在其中的评论。过去(虽然整个线程值得一读):

Alex Miller has commented on this in the past (the whole thread is worth reading though):


我想说内部机制具有一定程度的公开性

I'd say there is a range of "public"-ness to the internals of Clojure.


  • 新的Clojure API(clojure.java.api.Clojure)是Clojure外部调用者的官方公共API。该API基本上由解析var和调用函数的方法组成。

  • 对于Clojure中的Clojure用户,几乎任何公开的,具有文档字符串的var都可以在api文档中显示出来。

  • 私有或没有文档字符串(这样var从公共api文档中省略了)的Clojure变量很可能会非常小心。

  • Clojure内部Java接口[ clojure.lang ]的确旨在允许库建设者创建在Clojure世界中发挥作用的有用内容。我不知道有人曾说过他们是公开的,但我当然认为对核心接口的任何更改都可能破坏外部用户,这一点将被仔细考虑。

  • 在大多数情况下,Clojure内部Java类[ clojure.lang ]应该被视为私有的,如有更改,恕不另行通知。即使在那儿也有灰色区域。

  • 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.lang真的只是实现细节吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆