在一个方法（被调用者）中如果想要获取调用者的绑定，最简单有效的方法自然是设置一个参数让调用者将其绑定传递过来。
def foo(binding)
eval("local_variables", binding)
end
bar = 1
p foo(binding) # => [:bar]
然而这种途径会使得每次调用方法都多出一个额外的参数，有时可能会使方法调用显得不太美观。这时，我们可以采用传递块的方式来实现相同的功能——让调用者在调用被调用者时附带一个空的块，并让被调用者将其转换为一个 Proc 对象，然后通过 Proc#binding 获取到调用者的绑定。当然，如果被调用者本身就需要一个块，自然就不用专门在调用时附带一个 dummy 的块了。
def foo(&block)
eval("local_variables", block.binding)
end
bar = 1
p foo {} # => [:bar]
可是这种方法仍然修改了调用方法的形式。难道在调用者不传递任何信息的情况下被调用者就无法获取调用者的绑定了吗？在 Ruby 语言层，似乎并没有现成的接口提供这样的功能，所以我们只能另辟蹊径。自行创建一个类似于调用栈的“绑定栈”来跟踪不同调用者的绑定就是一个可行的办法，虽然它带来了一定的开销。
class Binding
@@call_binding_stack = [ nil, TOPLEVEL_BINDING ]
class << self
def caller_binding
@@call_binding_stack[-2]
end
def push_caller_binding(binding)
@@call_binding_stack.push(binding)
end
def pop_caller_binding
@@call_binding_stack.pop
end
end
end
set_trace_func lambda { |event, file, line, id, binding, klass|
return if klass == Binding
case event
when 'call'
Binding.push_caller_binding(binding)
when 'return'
Binding.pop_caller_binding
end
}
def foo
eval("local_variables", Binding.caller_binding)
end
bar = 0
p foo # => [:bar]
Kernel#set_trace_func 可以让我们安装一个钩子，让解释器在所有方法被调用和返回时都回调我们的钩子过程，也就是这里的 lambda 闭包。方法调用时，我们就将当前的绑定压入绑定栈；方法返回时，我们就出栈。绑定栈初始时有两个元素，一个是 nil，这是因为顶层没有调用者；一个是 TOPLEVEL_BINDING，这是因为在顶层调用的方法，调用者自然是顶层本身。栈的顶部永远是当前（被调用者）的绑定，所以为了获取到调用者的绑定，我们需要返回顶部下面的第一个元素。
`Module#undef_method’ 是一个值得注意的方法。它的作用是将一个方法从方法分派的任务中移除，使得调用该方法者收到一个 `NoMethodError’ 异常（即 `obj.respond_to? :method => true’）。然而，`undef_method’ 并非是把方法彻底从类结构中移除了，它仅仅是将以符号表示的方法名所标识的方法标记为“未定义”，使得解释器在通过方法分派、反射等机制寻找这个方法时会立即抛出异常。这就逻辑蕴含了另一个事实：哪怕基类或是 mixed-in 模块有同名的方法，在派生类的同名方法被 `undefine_method’ 处理后，也不会尝试进行向上搜寻的方法分派。
`Module#undef_method’ 还有一个家族成员——`Module#remove_method’。它彻底从当前模块（即 `remove_method’ 的接收者。一个 `Module’ 的实例）结构中移除一个方法的引用。如此一来，方法分派函数在派生类中找不到一个方法，就会尝试在基类中寻找。
class Base
def bar
p :'base bar'
end
end
class Derivation < Base
def bar
p :'derivation bar'
end
end
d = Derivation.new
class Derivation
remove_method :bar
end
d.bar # => :"base bar"
class Derivation
undef_method :bar
end
d.bar # => NoMethodError
可见 `remove_method’ 后仍然能找到基类的 bar 方法，但 `undef_method’ 后却不能。
再演示另外一个和 eigenclass （Ruby 单例类）有关的例子：
obj = Object.new
def obj.foo
p self
end
p obj.respond_to? :foo # => true
class << obj
undef_method :foo
end
p obj.respond_to? :foo # => false
Marshal.dump(obj) # => error
可以发现，仅仅是 `undef_method’ 并不会移除 eigenclass 中的 eigenmethod（单例方法），所以它不能被 `Marshal’ 模块 dump。当我们把 `undef_method’ 替换为 `remove_method’ 后，就可以 dump 了。
在方法被标记为未定义或彻底移除之前通过反射获取的该方法的 `Method’ 对象，在之后仍然能正常运作：
class Klass
def foo
p :'Klass#foo'
end
end
obj = Klass.new
def obj.bar
p :'obj.bar'
end
m_foo_unbound = Klass.instance_method :foo
m_foo = obj.method :foo
m_bar = obj.method :bar
class Klass
remove_method :foo
end
class << obj
remove_method :bar
end
p obj.respond_to? :foo # => false
p obj.respond_to? :bar # => false
m_foo_unbound.bind(obj).call # => :"Klass#foo"
m_foo.call # => :"Klass#foo"
m_bar.call # => :"obj.bar"
这同时也演示了方法的绑定和方法分派相互独立的特性。
最后，Ruby 还提供了一个语法糖 `undef’ 以更简洁的语法（后面可以跟上一个纯粹的标识符，而无须符号或是其它字面值，类似与 `alias’ 这个语法糖）调用了和 Module#undef_method 相同的实现。`undef’ 是 Ruby 的关键字。
Ruby 和大部分 OO 语言一样，都是在语言、语法层仅支持单一方法分派的语言。单一分派（single dispatch）是在通过迟（动态）绑定实现多态时的一种思路，它依靠接收者的运行时类型动态地分派应该调用的方法。
Smalltalk、Python 以及 Ruby 使用的都是一种实现方式，那就是通过方法分派函数（dispatch function）和分派表（dispatch table）进行消息到方法的映射。每个类型在定义时就内置了这样的分派函数和分派表，后者是一个消息（符号）到实际方法的映射表，而前者接受一个输入符号，然后通过分派表映射到正确的方法（其间包含处理派生类继承的方法和模块 mixin 后的方法等比较复杂的过程）。当我们在 Ruby 中以 obj.method 的形式调用一个方法时，按照 Smalltalk 的程序语言概念，就是向 obj 这个对象发送了一个消息，传递了一个 :method 符号，而作为接收者的 obj 会通过分派函数在分派表中找到对应的方法。这整个过程就是所谓的动态方法分派（dynamic method dispatch）。
比如：基类和派生类有同名方法，但在实际调用时，随着接收者的不同，实际调用的方法也不同，当接收者是基类实例时调用基类实例方法，当接收者是派生类实例时调用派生类实力方法。关于这个的更多信息，还可以参考本主题早期的一篇关于迟绑定的回帖。
既然 Ruby 使用的分派模式唤作单一分派，那自然还有多重分派（multiple dispatch）。Common Lisp 是一个众所周知的最早支持多重分派的语言。多重分派通常是指在动态判断接收者类型的同时也判断方法参数的动态类型的分派模式。更有甚者，会判断参数的值，返回类型，或返回值。
要注意这里是方法参数的动态类型（运行时类型），而不是静态类型，这是关键。对于支持静态类型的语言来说，由于方法参数的类型可以在编译时决定，所以他完全可以做静态分派，也就是静态绑定（早绑定）。静态类型语言中的方法重载就是这样的一个概念——静态类型的参数在编译时就可以确定，所以方法的分派也是静态的。
比如，C++ 的方法重载，就是通过不同的静态类型的参数实现的，这个过程不属于动态分派，自然也就不能称之为多重分派。实际上，大多数 C++ 编译器都会给重载的方法/函数进行一个所谓的方法名/函数名装饰（function name decoration）的处理，所以在链接的时候，实际参与链接使用的正式函数名并不是你在源代码中敲下的函数名，而会有一些别的奇怪的符号，这个想必自己写过 C++ 共享库的朋友都深有体会。动态多重分派的严格定义，是指方法名不变，根据接收者和参数类型（甚至参数值、返回类型、返回值）判断应该调用的方法的一种多态。当然，由于 C++ 本身有虚函数的机制，所以还是支持动态分派的，只不过不支持多重分派罢了。
像后来的 Java 这样的静态类型语言，看起来也是支持方法重载，实际上也和 C++ 一样，只是单一分派罢了。C# 是个怪胎，C# 4.0 同时支持静态类型和动态类型，这使得多重分派在 4.0 中得到了支持。Python、Ruby 都是没有静态类型的语言，所以不可能像 C++ 那样去根据静态类型在编译时做函数名装饰，也就不可能有静态分派。因此，传统意义上的方法重载在这样的纯动态类型语言中是不存在的。由于不能重载，相同名称的方法就只有一个定义，所以在语言层、语法层是不能实现多重分派的。要想在仅支持单一分派的语言中使用多重分派，只能在高层模拟进行，比如 Ruby 可以通过 Object#class 去判断对象的运行时类（型），然后根据类型的不同分别处理。很多第三方的扩展库就是这么做的。
def foo(bar)
case bar
when String
p 'bar'
when Symbol
p :bar
end
end
foo :foo
foo 'foo'
输出：
:bar
"bar"
在 Ruby 1.8 中有一个内置类 Continuation，中文直翻是“延续”。这是计算机科学中一个比较底层的概念，它表示进程执行的某一特定时刻的计算过程的实例。通俗的讲，它就是 Ruby 中比 Binding 更加底层的一个能保存当前进程执行环境的物件，就好比游戏里，我们通过存档就能在环境改变之后重新读档，从档案记录的环境，记录的那一刻开始。“延续”一词，即是暗示了从记录的计算过程中的一个点继续执行之意。
Ruby 程序（CRuby 实现）的执行使用了相比于堆要更高效的栈结构来进行函数调用和局部变量的保存，而 Continuation 正是保存了进程运行在某一时刻时的栈内存状态，之后用户可以手动地去调用这个 Continuation 对象，让程序从这一个预先保存的记录点运行。这相当于不少语言中支持的 goto 语句跳转的一个超级版，因为 goto 只能进行局部跳转，而 Continuation 能上天入地，翻江倒海，一个筋斗十万八千里（实际上在 C 标准库中，Continuation 的功能是等同于 setjmp 和 longjmp 这两个函数所提供的功能的）。
有什么用？RM 有一个快捷键为 F12 的重置游戏的功能，当触发了这个命令时，RM 会让解释器从头开始重新执行脚本编辑器里的脚本，但并没有初始化符号表、GC 和堆结构。这使得原有的全局变量、常量、模块、类得以保存，但也可能会让我们与我们的老朋友——stack level too deep——再度重逢。由于脚本中大量使用 alias 别名方法，当 F12 按下后，没有进行判断的 alias 语句再次执行，就会导致两次同名一个方法后产生的经典 BUG（关于这个问题，这里不再赘述，论坛上已经有太多相关的帖子，请自行搜索 stack level too deep）。这个问题可以通过 method_defined? 等方法判断将要 alias 的方法是否已经定义来解决（alias 一次后方法就已定义了，第二次不会再定义），但并不是所有脚本编写者都有这个习惯。这里我们介绍一种使用 Continuation 的通用解法：
在 Main 脚本里的第一行插入一句：
callcc { |$__f12_no_reeval| }
这一句脚本让 RM 在执行到 Main 脚本时将一个保存了当前执行环境的 Continuation 对象赋给了 $__f12_no_reeval 这个全局变量；接着在脚本编辑器开头插入：
$__f12_no_reeval and $__f12_no_reeval.call
这句是先判断 $__f12_no_reeval 是否已初始化（即已经执行到 Main 脚本一次以上），如果是则调用这个 Continuation，让程序直接跳转到 Main 脚本开头的环境继续执行，避免了从开头到 Main 脚本之间的所有脚本的重新执行。由于产生冲突的、包含 alias 的脚本在这些脚本之中，保证只执行它们一次就从根本杜绝了这个问题的滋生。
在 Ruby 1.8 中，Continuation 的实现模型是与线程的实现模型一致的——线程调度器在进行绿色线程切换的时候，会进行类似 Continuation 的环境跳转。在 Ruby 1.9 中，由于 YARV 虚拟机采用的是本地线程，每个线程拥有自己的私有栈，他们之间就产生了区别。有趣的是，在 Ruby 1.9 中又引入了一个新的和 Continuation 类似的概念，那就是我们的 Fiber（纤程），一种轻量级的线程，它基本可以被看作是 Continuation 的替代品，同时由于效率比 Continuation 高（Continuation 保存栈内存状态的过程开销是巨大的），Ruby 社区就是否保留 Continuation 进行了激烈的辩论，就 1.9 而言，Continuation 仍然被作为标准库保留了下来。
在计算机科学中，“绑定”（Binding）一词是指一个更复杂、更大型的物件的引用的创建。例如当我们编写了一个函数，这个函数名就绑定了该函数本体，我们可以通过函数名来引用并调用该函数，这被称为名称绑定；又如当 Ruby 通过 API 去调用了 C 语言写的库函数时，这就是一个语言绑定；再如面向对象语言中的方法调度 obj.method，这也是一个名称绑定，它会根据接收者 obj 具体的对象类型来确定应该引用哪个对象类型的 method 方法，而如果 obj 在编译时就能确定，那便可称之为静态绑定（早绑定），早期的静态类型语言（如 C）使用的是早绑定；如果 obj 在运行时才能确定，那便可称为动态绑定（迟绑定），动态类型语言（如 Ruby）使用的是迟绑定，而有些语言则同时支持早绑定和迟绑定，如 C++ 的虚函数使用迟绑定，普通函数则使用早绑定。
在 Ruby 中，Kernel 有一个方法 binding，它返回一个 Binding 类型的对象。这个 Binding 对象就是我们这里说的绑定，它封装了当前执行上下文中的所有绑定（变量、方法、语句块、self 的名称绑定），而这些绑定直接决定了面向对象语言中的执行环境。比如，当我们调用 p 时，实际上是进行了 self 和 p 的绑定，而 p 具体是哪个方法，是由 self 的类型来决定的，如果我们在顶层，而 Kernel#p 又没有被重写，那 p 就是一个用来显示对象细节的方法。可以说有了一个绑定的列表，我们就有了一个完整的面向对象上下文的拷贝，就好比上帝在 12 分 37 秒复制了一份世界，而这个世界与原本世界的环境一模一样，既有这朵花，又有那株草。Ruby 的 Binding 对象的概念和 Continuation 有共通之处，但 Continuation 主要用于实际堆、栈内存的环境跳转，而 Binding 则比较高层。
这个 Binding 对象有什么用？主要是用于 eval 这个函数。eval 的第一个参数是需要 eval 的一段脚本字符串，而第二个可选参数则接受一个 Binding 对象。当指定了 Binding 时，eval 会在传递给它的 Binding 所封装的执行环境里执行脚本，否则是在调用者的执行环境里执行。我们可以通过这个机制来进行一些不同上下文之间的通信，或者是在一个上下文即将被销毁之前保存该上下文环境以留他用，如：
def foo
bar = 'baz'
return binding
end
eval('p bar', foo)
这里我们通过 foo 返回的 Binding 获取到了局部上下文销毁前的局部变量 bar 的值，而在不使用 binding 的情况下，局部变量 bar 在 foo 外层是不可见的。
最后，Ruby 有一个预定义的常量：TOPLEVEL_BINDING，它指向一个封装了顶层绑定的对象，通过它我们可以在其它上下文中通过 eval 在顶层上下文环境中执行脚本。
第七水螰 