疑问：yield到底是怎么运作的?

class A
def self.test
yield
end
end
class B
def test0
puts "call from class B"
end
def test1
A.test {test0}
end
end
b = B.new
b.test1

def test1
A.test {test0}
end

def test1
A.test {@this.test0}
end

First, a block may appear only in the source adjacent to a method call; the block is written starting on the same line as the method call’s last parameter (or the closing parenthesis of the parameter list). Second, the code in the block is not executed at the time it is encountered. Instead, Ruby remembers the context in which the block appears (the local variables, the current object, and so on) and then enters the method. This is where the magic starts.
Within the method, the block may be invoked, almost as if it were a method itself, using the yield statement. Whenever a yield is executed, it invokes the code in the block.When the block exits, control picks back up immediately after the yield.1 Let’s start
with a trivial example.

def three_times
yield
yield
yield
end
three_times { puts "Hello" }
produces:
Hello
Hello
Hello

你可以把省略的&block参数理解为你说的隐藏的this，但本质上和c++的this有区别的，ruby的self才和c++的this相似。

test0和test1在一个类里，test1当然知道test0。 你如果在test0里puts self就会看见输出的是B的实例。所以yield运行时动态切换context的，不是宏那样静态替换掉的。

BTW, 你竟然用了code框却不缩进？哼哼。另外有个手误：putc

context切换是肯定要的，因为反过来就不自然嘛，你写的代码你根本不知道运行在何种context下，你得去猜测那种context下有些什么东东。

不过这里是用例子证明了这一样，但我还是愿意反过来想：如果不切换context，那么block所处的context将是不自然的、不完整的，所以ruby开发者设计成需要context切换。。。似乎所有语言中类似的玩意都是这么设计的，可以想像成其它语言的委托。

context切换是肯定要的，因为反过来就不自然嘛，你写的代码你根本不知道运行在何种context下，你得去猜测那种context下有些什么东东。

不过这里是用例子证明了这一样，但我还是愿意反过来想：如果不切换context，那么block所处的context将是不自然的、不完整的，所以ruby开发者设计成需要context切换。。。似乎所有语言中类似的玩意都是这么设计的，可以想像成其它语言的委托。

所以，有人用yield也能实现类似微线程之类的东西。

关于coroutine, yield, iterator， ajoo有些文章和代码可以作为很好的参考。

http://jroller.com/page/ajoo?entry=yield_support_in_java
这个blog讲述了基本思想。

http://www.sourceforge.net/projects/jfunctional
这个项目的代码包括了一个 yield package，是 yield coroutine iterator的实现。

-------

另外, c#支持coroutine yield iterator。
我找到了一篇CLR关于这方面支持的ppt文档，有兴趣可以参阅。

http://research.microsoft.com/workshops/SSCLI2005/presentations/Ierusalimschy-Mascarenhas.ppt

聪明的人们把目光转向了Coroutine。
Coroutine本来是一个通用的概念。表示几个协同工作的程序。
比如，消费者/生产者，你走几步，我走几步；下棋对弈，你一步我一步。
由于协同工作的程序通常只有2个，而且这两个程序交换的数据通常只有一个。于是人们就很容易想到用Coroutine来实现Iterator。
这里面Iterator就是Coroutine里面的生产者Producer角色，数据提供者。所以，也叫做Generator。
每次Iterator程序就是等在那里，一旦用户（消费者Consumer角色）调用了iterator.next, Iterator就继续向下执行一步，然后把当前遇到的内部数据的Node放到一个消费者用户能够看到的公用的缓冲区（比如，直接放到消费者线程栈里面的局部变量）里面，然后自己就停下来（wait）。然后消费者用户就从缓冲区里面获得了那个Node。
这样Iterator就可以自顾自地进行递归运算，不需要自己管理一个栈，而是迫使计算机帮助它分配和管理运行栈。于是就实现了幸福得像花儿一样，简单得像Visitor一样的梦想。

比如，这样一段代码，遍历一棵二叉树。
public class TreeWalker : Coroutine {
private TreeNode _tree;
public TreeWalker(TreeNode tree) { _tree = tree; }
protected override Execute() {
Walk(_tree);
}
private void Walk(TreeNode tree) {
if (tree != null) {
Walk(tree.Left);
Yield(tree);
Walk(tree.Right);
}
}
}

其中的Yield指令是关键。意思是，首先把当前Node甩到用户的数据空间，然后自己暂停运行（类似于java的thread yield方法或者object.wait方法），把自己当前运行的线程挂起来，这样虚拟机就为自己保存了当前的运行栈（context）。
有人说，这不就是continuation吗？
对。只是Coroutine这里多了一个产生并传递数据的动作。
实现原理如果用Java Thread表示大概就是这样。当然下面的代码只是一个示意。网上有具体的Java Coroutine实现，具体代码我也没有看过，想来实现原理大致如此。

public class TreeIterator implements Iterator{
TreeWalker walker;
// start the walker thread ..
Object next(){
walker.notify();
// wait for a while so that walker can continue run
return walker.currentNode;
}
}

class TreeWalker implements Runnable{
TreeNode currentNode;

TreeWarker(root){
currentNode = root;
} void run(){
walk(curentNode);
}

private void Walk(TreeNode tree) {
if (tree != null) {
Walk(tree.Left);
currentNode = tree;
this.wait();
Walk(tree.Right);
}
}
}

我们看到，Iterator本身是一个Thread，用户也是一个Thread。Iterator Thread把数据传递给User Thread。
说实话，我宁可自己维护一个Stack，也不愿意引入Coroutine这类Thread Control的方式来实现Iterator。
总结