编译函数的toString()中的未修改的全函数名

Question

当前函数实例以Java名称的修改版打印toString()`。

`
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](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问题的修复造成的。

顺便说一下，我不是知道哪些问题感兴趣的人。我知道这个问题已经得到了相当多的投票，并且投票数使它成为最受欢迎的增强建议之一 - 请在这个报告的“增强”部分下查看，或搜索1330: http://jafingerhut.github.io/clj-ticket-status/CLJ-top-tickets-by-weighted-vote.html

即将进入Clojure 1.7的功能基本上已经确定，相当多的其他修复和增强被推迟到1.8。超过一年的等待时间并不罕见，尤其是对于增强功能。

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

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