在2024年Clojure现状调查！中分享你的想法。

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

提问问题

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

0票
在 错误 由

目前函数实例在toString()中打印它们的JVM名称

`
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

How-ard，很抱歉我对你补丁中的更改没有更多有用的评论。目前我只有几条关于其形式的微小评论。补丁的首选格式是使用这个维基页面上显示的说明创建的格式：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票
由

评论者：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社区维护
...