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

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

提问

编译函数中状态函数未处理的完整名称

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。超过 1 年的等待时间并不罕见，尤其是对于增强功能。

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票
由
引用：[CLJ-1278](https://clojure.atlassian.net/browse/CLJ-1278)（由hlewisship报告）
由Cognitect维护，代表Clojure社区
...