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

在下面的第一条语句中，Pry返回了一个看起来很正常的对象。为什么Pry以不同的方式格式化这些返回值？

在第二，撬指定对象的λ，而且还增加了与@(pry)到撬会话（:37）内的线的基准。为什么第一个返回值不包含@(pry)？或者，相反，为什么第二个返回值包含它？

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

lambda {} 
# => #<Proc:[email protected](pry):37 (lambda)>

来源

2016-02-13 ulysses_rex

第二个例子是一个文字，和proc（拉姆达）的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:[email protected](irb):2>

来源

2016-02-14 02:35:08 sawa

这和Pry没有任何关系。这是您在这两个Proc上致电inspect时所得到的结果。

我不是100％肯定，但我有一个理论。在第二个示例中，您将一个块传递给lambda。尽管块中没有任何代码，但通常情况下，调试时（通常用于这种情况的行号）非常重要。

在第一个例子，虽然，有没有块。你在一个空的哈希上调用Hash#to_proc（这是无关的;你得到的结果与Symbol#to_proc等一样），所以没有代码将一个行号关联起来;一个行号甚至不会有意义。

你可以看到这种情况发生在proc_to_s功能proc.c，顺便说一句。

来源

2016-02-13 23:11:18

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

回答

相关问题