Clojure函数和具体化对象应该暴露一个公共静态字段以识别它们的正确Clojure名称

Question

有一些框架的例子尝试将Java类名称解耦为Clojure符号（包括命名空间）；这在报告异常时编写改进的、针对Clojure的特定调用堆栈很有用。

现有的库基于正则表达式匹配和猜测，有时可能会给出错误的结果，例如当命名空间或函数名称实际上包含下划线时。

如果Clojure能够在这些类上暴露一个静态最终字段，以显示应出现在调用堆栈中的正确名称，将有助于此类框架的作者；库然后能够使用反射来访问该字段的正确名称，而无需当前的猜测。

我建议将此类字段命名为CLOJURE_SOURCE_NAME。

除了函数之外的其他Clojure类构造，如具体化类型和协议实现，也将受益，尽管不清楚哪个确切字符串值可以正确且明确地识别该类的作用。

Answer 1

由：alexmiller发表的评论

FYI，即将有一个补丁提交1.6版，其中包含编译器中的新解耦函数。然而，由于其名称splice并不是总是可逆的，因此保留原始名称是一个好主意。

Answer 2

评论由：jafingerhut发表

Alex所提到的补丁已附加到CLJ-1083。

Answer 3

评论由：jafingerhut发表

Howard，这个工单与CLJ-1278之间似乎有些意图上的重叠。我猜它们中的任何一个都可以独立完成，但想确认一下。

Answer 4

评论者：dsg

这是我添加此功能的一个初始尝试。

一些注意事项

• 这将标记由 {{deftype}} 和 {{fn}} 生成的类。
• 这将处理包装的 {{fn}}，但输出将与标准的 {{demunge}} 函数略有不同：只有初始的 {{$}} 被转换成 {{/}}。
• 不幸的是，因为类型/记录构造函数的 {{defn}} 出现在一个 {{let}} 形式中，生成的符号与应有的符号不匹配。
• 没有公开的API可以从类中获取去感染的符号。也许 {{demunge}} 应该检查给定的名称是否对应于具有此字段的类？

我欢迎任何对此如何真正工作的意见。特别是，任何关于如何最好地处理非顶层形式的 {{defn}} 的想法。

Answer 5

评论由：jafingerhut发表

修改日期为2014年8月20日的补丁CLJ-1284-store-demunged-names.patch在2014年8月29日对Clojure进行了一些提交后无法干净地适用于最新的master。我没有检查在此之前是否可以干净地应用该补丁，也没有检查更新这个补丁可能容易或困难。

Answer 6

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