分享 聊聊 Ruby 中的 block, proc 和 lambda

kayakjiang · 2013年04月22日 · 最后由 ane 回复于 2017年05月25日 · 24623 次阅读
本帖已被设为精华帖!

做为热身,从一些简单的例子开始,

def f1
  yield
end

def f2(&p)
  p.call
end

def f3(p)
  p.call
end

f1 { puts "f1" }

f2 { puts "f2" }

f3(proc{ puts "f3"})

f3(Proc.new{puts "f3"})

f3(lambda{puts "f3"})

若你用的是ruby1.9及以上的版本,还可以这样,

f3(-> {puts "f3"})

上面是block, proc和lambda的一些基本用法。

block

先说说block, ruby中的block是方法的一个重要但非必要的组成部分,我们可以认为方法的完整定义类似于,

def f(零个或多个参数, &p)
  ...
end

注意&p不是参数,&p类似于一种声明,当方法后面有block时,会将block捕捉起来存放到变量p中,如果方法后面没有block,那么&p什么也不干。

def f(&p)
end

f(1)  #=> 会抛出ArgumentError: wrong number of arguments (1 for 0)异常

f()  #=> 没有异常抛出

f() { puts "f"} #=> 没有异常抛出

从上面代码的运行结果可以知道&p不是参数

def f(a)
  puts a
end

f(1) { puts 2}  #=> 没有异常抛出,输出1

所以任何方法后面都可以挂载一个block,如果你定义的方法想使用block做点事情,那么你需要使用yield关键字或者&p

def f1
  yield
end

def f2(&p)
  p.call
end

此时f1, f2执行时后面必须挂一个block,否则会抛出异常,f1抛出LocalJumpError: no block given (yield)的异常,f2抛出NoMethodError: undefined method 'call' for nil:NilClass的异常, ruby提供了block_given?方法来判断方法后面是否挂了block,于是我们可以这样修改f1和f2,

def f1
 yield if block_given?
end

def f2(&p)
  p.call if block_given?
end

这样的话,f1和f2后面无论挂不挂block都不会抛异常了。 我们再来看看f2修改前抛出的NoMethodError: undefined method 'call' for nil:NilClass异常,这种说明当f2后面没有挂block的时候p是nil,那么我们给f2挂个block,再打印出p,看看p究竟是什么,

def f2(&p)
  puts p.class
  puts p.inspect
  p.call
end

f2 {} # 输出Proc和类似<Proc:0x007fdc72829780@(irb):21>

这说明p是一个Proc实例对象,在ruby中,&还可以这么用,[1,2] & [2,3] 或者 puts true if 1 && 1 或者在某个类中将它作为一个方法名。

很多ruby老鸟会写类似下面的代码,

["1", "2", "3"].map(&:to_i),其效果和["1", "2", "3"].map {|i| i.to_i }一样, 但简洁了许多,并且更加拉风。 这里的魔法在于符号&会触发:to_i的to_proc方法, to_proc执行后会返回一个proc实例, 然后&会把这个proc实例转换成一个block,我们需要要明白map方法后挂的是一个block,而不是接收一个proc对象做为参数。&:to_i是一个block,block不能独立存在,同时你也没有办法直接存储或传递它,必须把block挂在某个方法后面。

:to_i是 Symbol 类的实例, Symbol 中的to_proc方法的实现类似于,

class Symbol

  def to_proc
    Proc.new {|obj| obj.send(self) }
  end

end

同理我们可以给自己写的类定义to_proc方法,然后使用&耍下酷,比如,

class AddBy

  def initialize(num = 0)
    @num = num
  end

  def to_proc
    Proc.new {|obj| obj.send('+', @num)}
  end

end

add_by_9 = AddBy.new(9)
puts [1,2,3].map(&add_by_9) #输出 [10, 11, 12]

在ruby中, block有形,它有时候是这样

do |...|
  ...
end

有时候是这样

{|...| ...}

或者类似 &p, &:to_i, &add_by_9之类,但是它无体,无体的意思就是说block无法单独存在,必须挂在方法后面,并且你没有办法直接把它存到变量里,也没有办法直接将它作为参数传递给方法,所以当你想存储,传递block时,你可以使用proc对象了,

 p = Proc.new(&:to_i)
 p = Proc.new {|obj| obj.to_i } 
 p = Proc.new do |obj|
   obj.to_i
 end
 p = proc(&:to_i)
 p = proc {|obj| obj.to_i}
 p = proc do |obj|
   obj.to_i
 end

def make_proc(&p)
  p
end

p = make_proc(&:to_i)
p = make_proc do |obj|
  obj.to_i
end
p = make_proc {|obj| obj.to_i }

虽然我在开发中经常用到block,但是我很少显式地去使用Proc或proc去实例化block,比如我几乎没有写过这样的代码,

f(Proc.new {|...| ...})

f(proc {|...| ...})

p =  Proc.new {|...| ...} #然后在某个地方p.call(...)或者将p传递给某个方法,比如f(p)

在使用block时,我会忽略proc的存在,我将proc定位为一个幕后的工作者。我经常写类似下面的代码,

def f(...)
  ...
  yield
  ...
end

def f(..., &p)
  ...
  p.call
  ...
end

def f(..., &p)
  instance_eval &p
  ...
end

def f(..., &p)
  ...
  defime_method m, &p
  ...
end

有些新手会写类似下面的一执行就会报错的代码,

def f(..., &p)
  instance_eval p
end

def f(..., p)
  instance_eval p.call
end

也有这样写的,

def f(..., &p)
  instance_eval do
    p.call
  end
end

或者

def f(...)
  instance_eval do
    yield
  end
end

我甚至写过类似下面的代码,

def f(...)
  instance_eval yield
end

我们经常在该挂block的时候,却把proc对象当参数传给方法了, 或者不明白&p就是block可以直接交给方法使用,我曾经也犯过这样的错误就是因为没有把block和proc正确的区分开来, &p是block, p是proc,不到万不得已的情况下不要显式地创建proc,每当我对block和proc之间的关系犯糊涂时,我就会念上几句。

再来聊聊yield和&p,我们经常这样定义方法,

def f(...)
  yield(...)
end

def f(..., &p)
  p.call(...)
end

yield和call后面都可以接参数,如果你是这样定义方法

def f(...)
  yield 1, 2
end

那么可以这样执行代码,

f(...) do |i, j|
  puts i
  puts j
end

但是这样做也不会有错,

f(...) do
  ...
end

p.call(...)的情况类似, 也就是说block和proc都不检查参数(其实通过proc方法创建的proc在1.8是严格检查参数的,但是在1.9及以上的版本是不检查参数的),为什么block和proc不检查参数呢?其实这个很好理解,因为在实际应用中你可能需要在一个方法中多次调用block或者proc并且给的参数个数不一样,比如,


def f()
  yield 0
  yield 1, 2
end

def ff(&p)
  p.call 0
  p.call 1, 2, 3
end

f do |a1, a2, a3|
  puts a1   
  puts a2
   puts a3
end

由于方法后面只能挂一个block,所以要实现上面的代码功能,就不能去严格检查参数了。

转入正题,这两种方式效果差不多,都能很好地利用block。使用yield,看起来简洁,使用&p,看起来直观,并且你可以将&p传给其他方法使用。 但是在 ruby1.8 的版本你不应像下面这样做,

def f1(...)
  eval("yield")
end

可以,

def f2(..., &p)
  eval("p.call")
end
f1(...) {}  # 会抛异常
f2(...) {}  # 正常运行

当然上面这种用法很少见,但是却被我碰到了,我经常写一些方法去请求外部的api,有时这些外部的api不是特别稳定,时不时会遇到一些bad respoense, timeout错误,针对这些错误,应该立即重发报文重试,对于其他异常就直接抛异常。于是我写了一个try方法来满足这个需求,


  def try(title, options = { }, &p)
    ee = '#{e}'
    tried_times = 0
    max_times = options[:max_times] || 3
    exceptions = options[:on] || Exception
    exceptions = [exceptions] if !exceptions.is_a?(Array)
    rescue_text = <<-EOF
      begin
        p.call
      rescue #{exceptions.join(',')} => e
        Rails.logger.info("#{title}发生异常#{ee}")
        if (tried_times += 1) < max_times
          Rails.logger.info("开始重试#{title}--第#{tried_times}次重试")
          retry 
        end
        raise e
      end
    EOF
    eval rescue_text
  end

try('某某api', :max_times => 2, :on => [Net::HTTPBadResponse, Timeout::Error]) do
  open(api_url)
end

最开始我用的是yield,结果在 ree 下执行try方法时会报错,后来改成使用&p就通过了。

通过试验发现在 ruby1.9 及以上版本已经没有这种差异了。

做个小结, block和proc是两种不同的东西, block有形无体,proc可以将block实体化, 可以把&p看做一种运算,其中&触发p的to_proc方法,然后&会将to_proc方法返回的proc对象转换成block

其中proc对象的to_proc方法返回自身。

p = proc {}
p.equal? p.to_proc  # 返回true

lambda

lambda是匿名方法, lambda和proc也是两种不同的东西,但是在ruby中lambda只能依附proc而存在,这点和block不同,block并不依赖proc。

l = lambda {}
puts l.class 

ruby1.8 中输出的信息类似#Proc:0x0000000000000000@irb):1( 在 ruby1.9 及以上版本输出的信息类似#Proc:0x007f85548109d0@irb):1lambda)(,注意 1.9 及以上版本的输出多了 (lambda),从这里可以理解ruby的设计者们确实在有意的区分lambda和proc,并不想把lambda和proc混在一起,如同ruby中没有叫Block的类,除非你自己定义一个,ruby中也没有叫Lambda的类,于是将lambda对象化的活儿就交给了Proc,于是令人头大的情况出现了,当你用lambda弄出了一个匿名方法时,发现它是一个proc对象,并且这个匿名方法能干的活,proc对象都能做,于是我们这些码农不淡定了,Proc.new {}这样可以, proc {}这样也没有问题, lambda {}这样做也不错, ->{}这个还是能行,我平时吃个饭都为吃什么左右为难,现在一下子多出了四种差不多的方案来实现同一件事情,确实让人不好选择,特别是有些码农还有点小洁癖,如果在代码里一会儿看到proc{}, 一会儿看到lambda{},这多不整洁啊,让人心情不畅快。在这里我们认定lambda 或者 -> 弄出的就是一个匿名方法,记做 l, 即使它披着proc的外衣,proc或者Proc.new创建的就是一个proc对象,记做 p 在ruby各个版本中, lp 是有一些差别的。

定义一些方法,


def f0()
  p = Proc.new {return 0}
  p.call
  1
end

def f1()
  p = proc { return 0 }
  p.call
  1
end

def f2()
  l = lambda { return 0}
  l.call
  1
end

def f3(p)
  instance_eval &p
  1
end

class A
end

def f4(p)
  A.class_eval &p
  1
end

p1 = Proc.new { }
p2 = proc {}
l  = lambda {}

def f5()
  yield 1, 2
end

f5 {}
f5 {|i|}
f5 {|i,j|}
f5 {|i,j,k|}

lambda和proc之间的区别除了那个经常用做面试题目的经典的return之外,还有一个区别就是lambda不能完美的转换为block(这点可以通过f3和f4执行的过程得证),而proc可以完美的转换为block,注意,我说的lambda指的是用lambda方法或者->符号生成的proc,当然和方法一样lambda是严格检查参数的,这个特点也和proc不一样。

从上面的数据对比来看,在1.8版本,lambda和proc方法生成的proc对象的行为是一致的,但在1.9以上和jruby的版本中,lambda和proc的不同处增多,可以认为ruby的设计者们并不想把lambda和proc混同为一件事物。如我前面所讲,proc的主要作用是对象化block和lambda,并且proc在行为上更接近于block。

retrun的几个试验


def f0()
  p = Proc.new { return 0}
  p.call
  1
end

def f1()
  l = lambda { return 0}
  l.call
  1
end

f0 # 返回0
f1 # 返回1

如果你能够理解proc在行为上更像block,lambda其实就是方法只不过是匿名的,那么你对上面的结果不会感到惊讶。

如果把f0,f1做一些修改,就更容易理解上面的结果了。


def f0()
  return 0
  1
end

def f1()
  def __f1
    return 0
  end
  __f1
  1
end

f0 # 返回0
f1 # 返回1

return只能在方法体里执行


p = Proc.new { return 0 }
l = lambda { return 0 }

p.call # 报LocalJumpError
l.call # 返回0

构造p的时候我没有使用proc {return 0},因为在 ruby1.8 中, proc {return 0}的行为和lambda一样,比如在 ruby1.8 中,


def f(p)
  p.call
  1
end

p = proc { return 0 }
l = lambda { return 0 }

f(p)  # 返回1
f(l)  # 返回1

p.call # 返回0
l.call # 返回0

def f(p)
  p.call
  1
end

p = Proc.new { return 0 }
l = lambda.new { return 0}

f(p)  # 报LocalJumpError
f(l)  # 返回1

我感觉proc中的return能记住proc生成时其block的位置,然后无论proc在哪里调用,都会从proc生成时其block所在位置处开始return,有下面的代码为证:


def f(p)
  p.call
  1
end

def f2()
  Proc.new { return 0 }
end

def f3()
  lambda { return 0 }
end

p = f2()
l = f3()

f(p)  # 报LocalJumpError: unexpected return,from (irb):29:in `f2'
f(l)  # 返回1

我在1.8, ree, jruby, 1.9, 2.0各版本都测试过,结果一样。

再看看下面的代码,


def f0(&p)
  p.call
  1
end

def f1()
  yield
  1
end

f0 { return 0}  # LocalJumpErrorw
f1 { return 0}  # LocalJumpErrorw

f0(&Proc.new{return 0}) # LocalJumpError
f0(&lambda{return 0})   # 返回1

def f2(&p)
  p
end

def f3()
  p = f2 do
    return 0
  end
  p.call
  1
end

f3 # 返回0

我们重点看看f3中的proc p,它虽然是从f2中生成返回的,但是p生成时其block是处在在f3的方法体内,这个类似于,


def f3()
  p = Proc.new { return 0}
  p.call
  1
end

所以执行f3时,没有异常抛出,返回0。

总结

当你想写出类似于f do ...; end 或者 f {...}的代码时,请直接使用block,通过yield, &p就能达到目的,当你想使用proc时,其实此时绝大部分的情况是你实际想用lambda,请直接使用lambda{}或者->{}就可以了, 尽量不要显示地使用Proc.new{} 或者 proc{}去创建proc。

废话说了一大堆,其实我最想说的是: 用block,用lambda,不要用proc,让proc做好自己的幕后工作就好了

共收到 52 条回复

👍 Proc里写return会把call Proc的方法直接return掉是一个很奇怪的设计,一直被我认为违反了代码结构化。

#1楼 @iBachue Proc中的ruturn之所以如此表现是为了和block保持一致,所以我们平时写代码不要去碰Proc这颗雷,因为它形式上像lambda,里子却是block

最近也有看这部分的知识,不过还是学不透彻,有些东西混淆了⋯⋯

好长好长呀~~! 有机会一定细细品读.

讲的很清楚,就是略长~

《Ruby编程语言》 的 第6章 方法、Proc、Lambda和闭包 对这些概念做出了非常好的阐释。 有兴趣的可以看看。 其实这几个东西主要的区别就是编程里最让人头大的一个概念 作用域

另外感觉最近 瞎扯淡 的帖子越来越多,想这样研究技术的应该多鼓励,真心想多加几个红心,但我只能加一个。

@lgn21st @huacnlee @Rei 各位,是不是应该弄个精品贴聚合的功能,把这些技术贴按类别和版本收集起来。要不过几天就又被淹没了,这种帖子是有保留价值的。

首先赞 lz 的讲解。

但是不能理解为什么会有最后的结论。

用block,用lambda,不要用proc,让proc做好自己的幕后工作就好了。

我觉得用哪个取决于你要做什么,根据上面你讲的他们不同的特性去选择,若没有严格的限制的话,用哪个都没问题,除非希望代码风格上保持一致,可以都选择一种,但是没有所谓的 最好用哪个,最好别用哪个的 说法。

Sinatra 的代码中绝大多数,不,应该是所有 proc 的写法都是显式的使用 Proc.new.

支持弄个精品聚合,像上次那个删帖就很棒,只是希望楼主不要轻易删帖。

权限可设置一旦成为精品,任何人就无法删除。

很详细的对比解释,终于了解 ['1','2'].map(&:to_i) 的原理

哈哈, 好久不见啊.

每次我用的时候, 都是想到下面这关系 &proc => block

#8楼 @zgm 你说的对,sinatra中确实都是用的是Proc.new,他这样做看起来更面向对像些,他里面的很多配置是类似这样写的

set :raise_errors, Proc.new { test? }

这是可以用lambda代替的,sinatra做的比较好的一点就是始终如一的用Proc.new统一了风格。 看待问题的角度不同,处理问题的手段也就不一样了,我把Proc的主要功能定位于在幕后对象化block和lambda,所以在平时写代码的时候一般不用Proc.new,当然到了非要用Proc.new的时候,也就用了。

#12楼 @wxianfeng 好啊,我也是这么想的

#6楼 @hpyhacking 帖子的很多内容在《Ruby编程语言》都有讲到,我算是做了一次搬运工,然后做了些试验

#6楼 @hpyhacking 我从《Ruby元编程》里学到的最大的体会就是:class, module, def, proc, lambda等都是定义作用域的思想确实让人耳目一新。

#10楼 @reyesyang 这个部分似乎没有楼主讲得这么简单 ['1','2'].map(&:to_i)里还蕴含了很多奇怪的地方恐怕只能通过阅读Ruby源码来了解了

这个总结好。

我一直的笨办法就是记住:block就是一段代码,call的时候就是当前位置嵌入了代码;lambda相当于一个方法,call的时候就是方法调用

#20楼 @ghjcumt2008 总结哥,好!

#20楼 @ghjcumt2008 这么一说就更方便记了😄

@kayakjiang @iBachue 我现在知道了一般情况下应该 用block,用lambda,不要用proc,让proc做好自己的幕后工作就好,但是怎么解释Rails Guide 3.2.13里面推荐使用Proc,而不是lambda? http://guides.rubyonrails.org/active_record_validations_callbacks.html#using-a-proc-with-if-and-unless

#23楼 @ericguo 1. 例子中说并没有它推荐Proc啊

  1. 其实这里它强调的是Proc,而不是proc或是lambda,proc和lambda都是Proc对象,它这里的意思就是这里接受一个Proc对象,可以用Proc.new,可以用proc,可以用lambda,全都可以。作为教程它当然尽可能的把它所有能接受的参数都告诉你,但并没有推荐你去用proc或是lambda的意思。

#23楼 @ericguo 它的例子里确实是用Proc,可能看起来更加面向对象,不过这些例子用lambda也没有问题,还是看编程习惯吧,尽量做到风格统一

又仔细看了看,感觉还是#19楼 @goinaction 的比较好理解 block就是一段代码(由Proc.new或者proc创建,语义完全一样),call的时候就是当前位置嵌入了该代码块,属于ruby比较独特的特性;lambda相当于一个方法(由lambda或者->创建,语义完全一样),虽然还是由一段代码(block)组成,但和其他语言的闭包特性很类似,方法体内还可以使用包外的变量,于是return到哪里就很容易理解了,return只是现象,这个才是本质。

Rails Guide 3.2.13里面使用Proc,而不是lambda,也许是因为源码里面是这样起名调用的:

# BlockValidator is a special EachValidator which receives a block on initialization
# and call this block for each attribute being validated. +validates_each+ uses this
# Validator.
class BlockValidator < EachValidator
  def initialize(options, &block)
    @block = block
    super
  end
  def validate_each(record, attribute, value)
    @block.call(record, attribute, value)
  end
end 

https://github.com/rails/rails/commit/279067639f319f3b4bbcaf90c26f286e96df2c77

#27楼 @ericguo 呵呵,用Proc还是lambda与起什么名没有关系,你创建一个BlockValidator的实例对象试试。贴上你的代码

#26楼 @ericguo 这个不是本质啊 有意设计成这样的 为了尽可能接近method 实际实现其实和proc是类似的 否则这里lambda里的local variable也不应该包含a才对。。

#29楼 @iBachue lambada、proc实现上的本质肯定都是Proc对象 我觉得@ericguo 说的本质意思是设计上为啥要区分出lambda和proc,就是为了实现不同效果, 以在不同场合使用。

#28楼 @kayakjiang 用Proc还是lambda与起什么名的确没关系 #29楼 @iBachue 对,顺便略微修改了一下26楼。 感谢两位指导,说实话没有这样的讨论估计我是不会去花那么多时间搞Proc和lambda的特性比较的……

#26楼 @ericguo #19楼 @goinaction

我一直的笨办法就是记住:block就是一段代码,call的时候就是当前位置嵌入了代码;lambda相当于一个方法,call的时候就是方法调用

形象、好记忆。加一句“ block就是一段 绑定了当前作用域变量的代码, call的时候就在当前位置嵌入了代码”,就更完整了。

def m
  name = "张三"   
  yield              #这里和“张三”没有关系
end

m{p "hi, #{name}"}
#NameError: undefined local variable or method `name' for main:Object
name = "李四"        #当前域生成了name变量
m{p "hi, #{name}"}   #这时,name绑定了   ----(1)
#=>"hi 李四"
name = "王 二"
p1 = lambda{p "hi, #{name}"}    #这时name绑定了, 速度比(1)慢
m(&p1)  
#=>"hi 王二"

m{p "hi, #{name}"} 时 ,生成了内部Proc的对象。

block不是对象,可以转换成Proc对象,对象可以传递。

Proc的对象 和 Method的对象 可以相互转换。http://ruby-china.org/topics/10470

不绑定变量,嵌入代码:

def m(mimic) 
  name="zhang 3"
  instance_eval(mimic) 
end 
name = "li 4"
m %{p name}
#=>"zhang 3"

#26楼 @ericguo #19楼 @goinaction “嵌入代码” 只是便于理解。 block更接近method,传入的是 类似Java中的 “函数指针”。函数可以有调用参数。

#32楼例子中的”张三“可以通过块参数进入块中,这时用带参数的块调用。

def m
  name = "张三"     
  yield(name)   #调用传入参数
end
name = "李四"                  #这次和李四没有关系了。
m{|name|p "hi, #{name}"}   #name 是参数
#=>"hi, 张三“

#33楼 @zputee 呵呵,你这个例子不是很好,%{p name}是一个字符串,类似于

def m(mimic) 
  name="zhang 3"
  eval(mimic) 
end 
name = "li 4"
m "p name"

这等同于

def m
  name = "zhang 3"
  p name
end
name = "li 4"
m

这明摆着会输出 "zhang 3"。

#35楼 @kayakjiang ,代码块加引号就是字符串 😄 , 来一个真的代码块嵌入:

class C
  def initialize(name)
    @name = name
  end
end
cc = C.new("zhong 3")

@name = "li 4"
cc.instance_eval{
  def hi
    p @name          #调用嵌入对象cc中的实例变量 @name
  end
}
cc.methods(false)   #检查嵌入的代码
#=>[:hi]    
cc.hi              #调用嵌入的代码
#=>"zhong 3"

#36楼 @zputee 这个例子不错,如果这样改下效果可能更好些,可以排除def的干扰

  @name = "li 4"
  cc.instance_eval{
    p @name          #输出zhong 3
  }

 p = Proc.new { @name }

 puts p.call                        #输出的是 li 4

 cc.instance_eval &p           # 输出的是zhong 3,把proc的闭包特性直接无视了


class C
  def initialize
    @name = "zhong 3"
  end

  def hi(p)
     puts p.call
  end

   def hi2(&p)
      puts p.call
   end

end

C.new.hi(p)                 # 此时不能简单的认为proc会嵌入到hi方法中,实际输出的是 li 4
                                 # 如果proc在call的时候能嵌入到hi方法中,那么输出的应该是 zhong 3

C.new.hi2 do
   @name                    # 输出的是li 4
end

instance_eval是一个比较特殊的方法,感觉它可以无视proc的闭包性 在ruby1.9中,instance_eval不能挂lambda转换过来的proc,估计lambda的闭包性是强制的,无法无视了哈哈

#37楼 @kayakjiang 再来个嵌入

class C
  @name = "zhong3"
end

@name="li4"

ll = ->(word){p "#{word},#{@name}"}
C.singleton_class.send(:define_method,:say ,&ll)

C.say("hi")
#"hi,zhong3"

#38楼 @zputee 呵呵,不玩了,实际开发一般用不了这些东西,代码不能写的让别人看不懂

#38楼 @zputee 嗯,从参数检查,返回行为,上下文的绑定三个点出发就能掌握lambda和block的基本使用了

今晚拜读!

好文...挖坟顶上来....

mark一下

拜读完,感觉这待遇该涨涨了

#45楼 @luotuo 。。。,请多读读元编程

《Ruby 编程语言》看到第六章完全没看懂。

#48楼 @kayakjiang 嗯,有道理,非常感谢。

看完这个帖子 又一次明白:我以为我弄明白了一个问题,然而我才刚刚走到门口~~~ 关于 Proc 的 return,也试了一下,很同意 #1楼 的看法,略微有点坑,以后还是尽量避免这么用好了

51楼 已删除
chenge Ruby 学习汇集,请推荐内容 中提及了此贴 07月04日 11:35

你真的知道什么是 block 你这样容易误导初学者 好不好 傻X

哈哈,不是53楼,我是不会回这个帖子的。之所以要回,是因为已经不是2年前那么小白了。要想知道block, proc 和 lambda 的区别,没必要想楼主这样,靠似有若无的推测,你只需要看他们三个的C语言实现,就能看出他们的区别了,好像是在ruby.h,intern.h里吧。也没必要如此喷楼主

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册