编译函数的toString()中未处理的函数全名

Question

当前函数实例在打印toString()时会使用Java名称

`
user=> (ns proj.util-fns)
nil
proj.util-fns=> (defn a->b [a] (inc a))

'proj.util-fns/a->b

proj.util-fns=> a->b

object[proj.util_fns$a__GT_b 0x141ba1f1 "proj.util_fns$a__GT_b@141ba1f1"]

`

为了调试目的，如果函数的toString()描述了Clojure模式的fn名称将会非常有用。

方法：在函数实例中存储原始名称并在toString()中使用它而不是返回类名称。

`
proj.util-fns=> a->b

object[proj.util_fns$a__GT_b 0x47d1a507 "proj.util-fns/a->b(NO_SOURCE_FILE:2)"]

`

权衡：出于函数名称，函数实例大小增加。

补丁： CLJ-1278-2.patch

Answer 1

评论：由 hlewisship 提出

包含更改和更新测试。我没有关于这些更改是否以任何重大或可测量的方式影响了编译器性能或生成的代码大小的详细资料。

Answer 2

评论：由 jafingerhut 提出

Howard，很抱歉，我对你补丁中的更改没有更多有用的评论。目前我对它的形式只有几个小意见。补丁的理想格式是使用这个维基页面上的说明创建的：http://dev.clojure.org/display/community/Developing+Patches

此外，您补丁中的几个部分看起来只是在行间距上进行了更改。在建议的补丁中最好省略这种更改。

Answer 3

评论：由 hlewisship 提出

是的，我没有注意到空白更改，直到后来；尽管我尽力了，但是必须是在某个时候点击了格式化。我很快会整理一个新的补丁。

Answer 4

评论：由 hlewisship 提出

干净的补丁

Answer 5

评论：由 hlewisship 提出

顺便说一句，已经一年了。正确的文件是CLJ-1278-2.patch。

Answer 6

评论：由 hlewisship 提出

...嗯，最近有些事情改变了。

`

 [java] FAIL in (fn-toString) (fn.clj:83)
 [java] nested functions
 [java] expected: (= (simple-name (.toString (factory-function))) (str "clojure.test-clojure.fn/" "factory-function/fn"))
 [java]   actual: (not (= "clojure.test-clojure.fn/factory-function/fn__7565" "clojure.test-clojure.fn/factory-function/fn"))
 [java]
 [java] FAIL in (fn-toString) (fn.clj:83)
 [java] nested functions
 [java] expected: (= (simple-name (.toString (named-factory-function))) (str "clojure.test-clojure.fn/" "named-factory-function/a-function-name"))
 [java]   actual: (not (= "clojure.test-clojure.fn/named-factory-function/a-function-name__7568" "clojure.test-clojure.fn/named-factory-function/a-function-name"))

`

如果有任何迹象表明它将被选中，我愿意更新我的补丁。自从上次更新以来已经超过一年了。

Answer 7

评论：由 jafingerhut 提出

您所看到的这种行为变化最有可能是由于对票据CLJ-1330的修复。

顺便问一下，不，我不是知道哪些票据值得关注的人。我知道这个已经有了相当多的投票， votes使它是排名第一的提升建议之一 - 在这份报告的“提升”部分下看，或搜索1330: http://jafingerhut.github.io/clj-ticket-status/CLJ-top-tickets-by-weighted-vote.html

即将进入Clojure 1.7的功能已经基本确定，许多其他修复和提升被推迟到1.8。对于提升而言，超过1年的等待时间并不罕见。

Answer 8

评论：由 hlewisship 提出

感谢提供信息；不想显得任性问题，但对于那些想要改进事物的人来说，“大沉默”可能有些令人生厌。

我将更新我的补丁，希望能看到1.8版本的一些动态。

Answer 9

评论者：alexmiller

针对Clojure，有大约400张待处理工单。作为一个打印增强，这通常被认为比缺陷优先级低。此外，这个提案更改了编译器、字节码生成代码，并增加了生成的对象字段，这些改变有着未评估的广泛影响。这些变化的组合意味着我们可能还需要一段时间才能着手处理。

你可以采取以下措施来帮助
1) 简化描述。来到这个工单的人（审查者和Rich）希望通过最小努力来获取对问题的最大理解。我们有一些关于这个的指南在http://dev.clojure.org/display/community/Creating Tickets，如果你还没有看过的话。对于一个增强，最好是一段简短（1-2句）的问题描述和示例，我可以运行在 repl 上。然后是一个提案（尽可能简短）。例如：CLJ-1529、CLJ-1325、CLJ-1378。对于这种增强，看到（简洁的）用户将看到的版本之前/之后版本通常是最快让审查者理解效益的方法。

2) 预测并消除阻力。如上所述，你正在更改每个函数对象的大小。对大小和构建时间有什么影响？提供数据和/或测试工具可以节省审查者进行此类工作的时间。如果内容过长，最好将其放在附件或评论中，并在描述中引用它。

3) 让他人进行审查（见 http://dev.clojure.org/display/community/Screening Tickets） - 虽然审查者的工作（通常是本人）将需要重新进行，但在早期让更多的眼睛查看它有助于。在 #clojure 上询问是否有人可以查看、尝试等。如果有开放式问题，将这些问题留在描述中可以帮助我的工作。

Answer 10

评论：由 hlewisship 提出

Alex，谢谢你的建议。我会跟进的。其中一些数据已经存在，但我可以让它更突出。

我明白我在Tapestry问题列表上的问题数量（包括增强和较小改进）让我感到很繁重，所以对这个问题领域我有理解。

Answer 11

评论者：[email protected]

您还可以在AFn.java之类的类中实现toString()方法。

`
public String toString() {

String name = getClass().getSimpleName();
return Compiler.demunge(name);

}
`

Answer 12

评论者：alexmiller

Munge+demunge是一种有损操作。将demunge视为“尽力而为”，而不是可以依赖的东西。

Answer 13

参考：[url]https://clojure.atlassian.net/browse/CLJ-1278 (由hlewisship报告)[/url]