为Reflector添加对Big*数值类型的支持

Question

应该按预期工作，例如

{{(Integer. 1N)}}

可能适用于{{BigInt}}，{{BigInteger}}和{{BigDecimal}}。

请参阅 Rich 在 irc 中提到的{{c.l.Reflector.paramArgTypeMatch}}方法。

Answer 1

评论者：trptcolin

关于这对左移位影响的clojure-dev列表中的问题：http://groups.google.com/group/clojure-dev/browse_thread/thread/2191cbf0048d8ca6

Answer 2

评论者：ataggart

补丁CLJ-445也解决这个问题。

Answer 3

评论者：trptcolin

此补丁在位操作断言失败：(bit-shift-left 1N 10000)。原因是补丁已将（BigInt，Long）的分割从（Object，Object）更改为（long，int）。

显然，这不能应用（除非另一个更改使其成为可能），但我将其作为对话的开始。

Answer 4

评论者：ataggart

我来自邮件列表的评论

如果测试失败，很可能是因为选择了Numbers.shiftLeft(long,int)而不是Numbers.shiftLeft(Object,Object)
考虑到1N是一个对象（可以超出long类型大小的对象），所以方法选择是不正确的，因此补丁是无效的。
由于1N是一个对象，所以选择方法是不正确的，因此补丁是无效的。
将“简单”修改paramArgTypeMatch的建议并不充分，因为选择一个方法优于另一个方法的机制存在于编译器中，并且它们足够智能，无法做出这些决定。

---

由于选择一个方法优于另一个方法的机制存在于编译器中，并且不具有足够的智能来做出这些决定，因此对“简单地”修改paramArgTypeMatch的建议并不充分。

Answer 5

评论者：redinger

考虑将此内容移出Release.next - 征求Chas的意见。

Answer 6

_评论者：cemerick_

恐怕到目前为止我对涉及的问题并没有特别的见解。我曾在一周前遇到了这个问题，并在Rich的建议下提交了工单。如果工单的文本导致任何人走弯路，我感到很抱歉...

Answer 7

评论者：lvanderhart

与位运算有关的问题已经不再重要，因为我们决定只针对32/64位值使用位移操作。

仍然是一个有效的问题，但根据Rich的建议降低了优先级。

Answer 8

评论者：alexott

原始补丁的修改版本

Answer 9

评论者：jafingerhut

亚历克斯，你介意给它附上一个唯一的文件名吗？我知道 JIRA 允许我们使用相同的文件名创建多个附件，而且我知道我们可以通过创建附件的日期和上传者的账户来区分它们，但使用同样的名字似乎只会引起混淆。

Answer 10

评论者：alexott

将更新后的补丁重命名为唯一名称

Answer 11

参考： https://clojure.atlassian.net/browse/CLJ-666（由 cemerick 报告）