在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发表

Howards，很抱歉我对您在补丁中做出的更改没有更多有用的评论。现在我只有几条关于其形式的微小评论。补丁的推荐格式是使用此wiki页面上所示说明创建的： 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票
by

评论由：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 ） - 虽然筛选器（通常是我）将需要重做这项工作，但早期有更多的眼睛 reviewing 有助于。在#clojure上询问其他人看看，尝试它等。如果有开放性问题，将这些留在描述中有助于指导我的工作。

0票
by

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