在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发表的评论

霍华德，很抱歉我没有更多有用的评论关于你修补中的更改。目前我只有几个关于其形式的微小评论。补丁的首选格式是，使用此维基页面上的说明创建的：[http://dev.clojure.org/display/community/Developing+Patches](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) 预先考虑并消除障碍。正如我上面所提到的，您正在改变每个函数对象的大小。大小和构建时间会有什么影响？提供数据和/或测试框架可以节省审查人员的工作。如果在描述中篇幅较长，更好的是将详细信息留在附件或注释中，并在描述中引用它。

3) 让其他人审查（按照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票
由
参考：[Clojure Atlassian](https://clojure.atlassian.net/browse/CLJ-1278)（由hlewisship报告）
由Cognitect代表Clojure社区维护
...