为什么 Pry 以不同的方式格式化这些返回值？答案

【问题标题】：Why does Pry format these return values differently?为什么 Pry 以不同的方式格式化这些返回值？
【发布时间】：2016-02-13 21:58:27
【问题描述】：

在下面的第一个语句中，Pry 返回一个外观正常的对象。

在第二个中，Pry 在对象中指定了一个 lambda，但还添加了 @(pry) 并引用了 Pry 会话中的行 (:37)。为什么第一个返回值不包含@(pry)？或者反过来说，为什么第二个返回值包含它？

{}.to_proc
# => #<Proc:0x9b3fed0>

lambda {}
# => #<Proc:0x97db9c4@(pry):37 (lambda)>

【问题讨论】：

标签： ruby location proc

【解决方案1】：

第二个例子是一个字面量，proc (lambda) 是在 Ruby 代码中创建的，在那里它获取源位置。

在第一个示例中，proc 是通过执行 C 方法 (to_proc) 创建的。 C 代码被编译成 Ruby 解释器，变成二进制代码，用 C 位置代替 Ruby 源位置描述是没有意义的。实际上，您也不会获得该方法的源位置（这与它生成的 proc 的“源位置”不同，但应该接近它，如果要给出的话）：

{}.method(:to_proc).source_location # => nil

但是，如果源代码是作为 Ruby 代码的一部分编写的，您将获得源代码位置：

irb(main):001:0> def to_proc
irb(main):002:1>   Proc.new{}
irb(main):003:1> end
=> :to_proc
irb(main):004:0> {}.to_proc
=> #<Proc:0x007f387602af70@(irb):2>

【讨论】：

【解决方案2】：

这与 Pry 无关。这就是您在这两个 Procs 上调用 inspect 时得到的结果。

我不是 100% 确定，但我有一个理论。在第二个示例中，您将一个块传递给lambda。尽管您在块中没有任何代码，但通常情况下您会这样做，并且在调试时（inspect 通常用于）行号很重要。

但是，在第一个示例中，没有阻塞。你在一个空的哈希上调用Hash#to_proc（这是不相关的；你得到与Symbol#to_proc等相同的结果），所以没有代码可以关联行号；行号甚至没有任何意义。

顺便说一句，您可以在proc.c 的proc_to_s 函数中看到发生这种情况的位置。

【讨论】：