在2024 Clojure状态调查！中分享您的想法。

欢迎！请参阅关于页面以获取更多关于如何使用本网站的信息。

提问

编译后函数的toString()中未混淆的函数状态的全名

0 票
在 错误 由

当前函数实例以混淆的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为导向的函数名称将很有用。

方法：在函数实例中存储原始名称并在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

13 个答案

0 票
由

由：hlewisship发表的评论

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

0 票
由

由：jafingerhut发表的评论

霍华德，很抱歉我对你补丁中的更改没有更多有用的评论。目前我只有关于其形式的几个小评论。补丁的首选格式是使用此维基页面上的说明创建的：http://dev.clojure.org/display/community/Developing Patches

此外，您的补丁中似乎有一些部分只是对行内的空白进行了修改。最好将这些修改从提出的补丁中排除。

0 票
由

由：hlewisship发表的评论

是的，我没有注意到空白修改，直到之后；尽管我尽了最大努力，但可能是在某个时候点击了重置格式。我会很快整理出一个新的补丁。

0 票
由

由：hlewisship发表的评论

干净的补丁

0 票
由

由：hlewisship发表的评论

请注意，已经过去一年了。正确的文件是CLJ-1278-2.patch。

0 票
由

由：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"))

`

如果有任何迹象表明我的补丁可能被采用，我将愿意更新我的补丁。上次更新后已经过去一年多了。

0 票
由

由：jafingerhut发表的评论

您所看到的异常行为很可能是由针对票号CLJ-1330的修复引起的。

至于您是否想知道，不，我知道不是那些知道哪些票有吸引力的人。我知道这一票收到了相当多的选票，并通过投票成为了顶级增强建议之一——在报告的“增强”部分下查看，或搜索1330：http://jafingerhut.github.io/clj-ticket-status/CLJ-top-tickets-by-weighted-vote.html

即将集成到Clojure 1.7中的功能都已基本确定，还有相当数量的其他修复和增强被推迟到1.8。等待时间超过一年并不罕见，尤其是对于增强功能。

0 票
由

由：hlewisship发表的评论

感谢提供信息；我不想显得孩子气，但既是“大沉默”让人沮丧，想要帮助改进的人却无法得到回应。

我会更新我的补丁，并希望看到1.8版的一些动议。

0 票
by

评论者：alexmiller

对于Clojure，目前有约400个未解决的问题。作为一个打印增强，这通常被认为比缺陷的优先级低。此外，该提议更改了编译器、字节码生成代码，并向生成对象添加了字段，这些都可能带来未评估的广泛影响。这些因素的组合意味着我们可能需要一段时间才能开始处理它。

你可以做些什么来帮助
1) 简化描述。来到这个任务的人（审核者和最终的Rich）希望通过最少的努力了解最大的内容。如果您还没有看到，我们在这方面有一些指南：http://dev.clojure.org/display/community/Creating Tickets。对于一个增强，最好有一个简短的（1-2句）对问题的描述以及一个我可以运行的repl示例。然后是一个（尽可能简短）的建议。例如：CLJ-1529, CLJ-1325, CLJ-1378。对于一个类似的增强，看到（简洁的）前后版本，其中用户将看到这一点，通常是审核者最快理解好处的方法。

2) 预先考虑并去除阻碍因素。如上所述，你正在更改每个函数对象的大小。这对大小和构建时间有哪些影响？提供数据或测试环境可以节省审核者做这项工作。最好在附件或注释中留下细节，如果内容很长，则在描述中引用。

让其他人审核（如http://dev.clojure.org/display/community/Screening Tickets）——虽然这是审核者（通常是本人）的工作，但让更多人在早期审查它有助于。在#clojure上请求其他人看看、尝试等。如果有开放式问题，将这些留在描述中可以有助于指导我的工作。

0 票
by

由：hlewisship发表的评论

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

我知道我受到在Tapestry问题列表上的问题数量（包括增强和小的改进）的困扰，所以我理解这个问题空间。

0 票
by

评论者：[email protected]

你可以在类似于AFn.java的东西上实现toString()。

`
public String toString() {

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

}
`

0 票
由

评论者：alexmiller

Munge+demunge 是一种有损操作。将 demunge 视为“尽力而为”，而不是可靠的操作。

0 票
由
参考文献：[https://clojure.atlassian.net/browse/CLJ-1278](https://clojure.atlassian.net/browse/CLJ-1278)（由 hlewisship 报告）
由Cognitect代表Clojure社区维护
...