在 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 导向的 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

霍华德，很抱歉我没有关于你在补丁中进行的更改的更多有用评论。目前我只有关于其格式的几个小评论。补丁的首选格式是使用在此维基页面上的说明创建的格式：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号工单的修复而造成的。

至于您是否想知道，不，我不是知道哪些票据是重要的人。我知道这个票据获得了相当多的投票，其中之一是排名较高的增强建议——在这个报告的“增强”部分下查看，或者搜索1230：http://jafingerhut.github.io/clj-ticket-status/CLJ-top-tickets-by-weighted-vote.html

Clojure 1.7中将要添加的特性基本上已经确定，而有相当多其他的修复和增强被推迟到了1.8。比一年更长的等待时间并不罕见，尤其是对于增强功能。

0 票
由

评论者：hlewisship

感谢提供信息；不想表现得过于抱怨，但对想要改善事物的人来说，‘寂静的伟大’有一种不去理睬的感觉。

我会更新我的补丁，并希望看到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 票
由
参考：[https://clojure.atlassian.net/browse/CLJ-1278](https://clojure.atlassian.net/browse/CLJ-1278)（由 hlewisship 报告）
由Cognitect代Clojure社区维护
...