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

欢迎！请参阅 关于 页面了解更多此网站的工作方式。

提问

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

0 票
在 错误 由

目前函数实例在 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

13 答案

0 票
由

评论者：hlewisship

包含更改和更新的测试。我无法确定此更改是否会对编译器性能或生成的代码大小产生显著甚至可测量的影响。

0 票
由

评论者：jafingerhut

Howard，很抱歉对您在补丁中做出的更改没有更有用的评论。目前我只有一些关于其形式的轻微评论。补丁的首选格式是使用此维基页面上的说明创建的：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

感谢提供信息；我不想显得Grayish，但“伟大的沉默”对于想帮助改进事情的人来说是令人沮丧的。

我会更新我的补丁，并希望看到1.8的动向。

0 票
由

评论由：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 上询问其他人看看，尝试一下等。如果在描述中有开放问题，那么在描述中留下这些问题有助于引导我的工作。

0 票
由

评论者：hlewisship

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

我知道我对 Tapestry 问题列表上的问题数量感到不知所措（包括增强和微小改进），所以我理解问题空间。

0 票
由

评论由：[email protected] 参与

您可以在 AFn.java 这样的事物上实现 toString()。

`
public String toString() {

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

}
`

0 票
由

评论由：alexmiller 参与

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

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