New Groovy --- Closure/Block问题

所有新特性中争议最大的，当然就是此条：return/break/continue to behave inside closures like these statements work in other blocks (such as the block on a for() or while() loop.

简而言之，这就是统一block和closure。

这里我忍不住王婆卖瓜一下，其实我已经直觉出这个味道。我在1月16日在groovy-dev上re了Mike Spille一篇：

I think we should regard foo() {} as syntax-sugar, this feature eliminate the difference between built-in flow structure and user-defined method call.

If = { condition, doSth | if (condition) doSth() }



t = { println 'Hello!' }



if (true) { println 'Hello!' }    // built-in if



If (true) { println 'Hello!' }    // user-defined If is similar to

built-in if, that's groovy!



If(true, t)   // normal method call



If(true, { println 'Hello!' })  //  normal method call even the last

param is a anonymous closure



>

> The puzzling errors bit is also why I favor a keyword for closures. It'll

> not only greatly simplify the grammar and parser, but I think it's better

> for users too.  It clearly signals where closures are in your code, and

> avoids the problems of _users_ not knowing when they have a closure and

> when they have a block.

I think there is no essential difference between closure and block. User have a block, then want to reuse the block. make the block can be passed or returned or parameterized --- that is closure.

现在看来，当时我已经接近摆脱最初仅仅视closure为JavaScript中anonymous function等价物的想法了。我已经直觉到此closure与一般block之间的微妙关系。

closure的syntax很大程度上消除了内建流程结构和用户定义方法的区别。换言之，我们可以很方便的写出接受closure参数的方法，使得其调用语法能非常类似while, when（不带else的if）的语法结构！虽然还是无法复制for(;;)和if-else这样特殊的语法构造，但这已经是很大的震撼。

进而，我发现，就应用程序员角度而言，block和closure并不存在本质区别。block可以看作一个代码段，而closure是可以重用（可传递、返回以及参数化）的代码段。

然而closure和传统flow控制具有一定的冲突，这主要表现在如何实现break、continue语义。之前的建议一般是要求closure返回一个特定常量标记如Closure.BREAK来指示，然后由closure的调用者负有责任来处理此标志。

更大的问题在于，同样作为代码功能抽象和复用的单位，closure与function(method)发生了冲突。这就是要命的return问题！

显然，按照一般思路，closure在底层就是一个function或者说method，匿名closure形同block的 { param | expression } 的简洁构造可被视作一种语法sugar。并且从最初一直到现在，此sugar主要是为了达到精巧的GPath的简洁性。且另一方面，在从js或者是对泛函式编程（fp）有点入门知识的人看来，closure都应该与function划上等号。

应该说，groovy的closure一开始也是如此。唯一是，同样为了GPath的简洁性，采用了可省略return的设计（直接返回最后一个语句的值）。

从此，groovy的codebase中，所有closure几乎都没有return关键字的出现。因为几乎没有必要，所以似乎没有理由记得它甚至提到它。由此，一扇门打开了……

考虑一个传统程序。这个函数检查名为file的文件的每一行，并返回满足filter的第一行行号，否则返回-1。

def findLine(file, filter) {

    lineNo = 0

	f = new File(file)

	while(!f.isEOF()) {

		line = f.readLine()

		if (filter(line)) return lineNo;

		else   lineNo

	}

    return -1

}

现在一个newbie刚刚看了几个closure的例子，兴奋异常，于是换用closure style来撰写：

def findLine(file, filter) {

    lineNo = 0

    new File(file).eachLine { line |

        if (filter(line)) return lineNo; else   lineNo

    }

    return -1

}

Ok，一切看上去没错，代码更清晰的表达了程序的主旨，几乎没有多余的东西。

但是，不幸的是，这段程序在Classic Groovy里面是无法达到预期效果的，findLine总是返回-1！

因为在eachLine之后的匿名closure中的return是从该closure返回到eachLine方法内部的调用点上（事实上eachLine方法只是简单的忽略这个返回值，没有任何人期待它的到来），而不是如程序员所期望的返回给findLine的调用者！

ok，这是程序员的问题，误用了return——有人会简单的下结论。如何用建议的Closure.BREAK常量标志来达成这个功能先不论，仅仅考虑到这个return是多么直觉的事情，并且groovy的目标就是要让程序员能按直觉办事（去掉烦心的程序终结符;居然还允许跨行，就是例证），就不能简单的把问题归咎于程序员。

照例说，在这个结构里面，return的用意非常清楚，不带偏见的说，任何一个Java程序员转向groovy之后几乎都会写出这样的程序。由于 closure大量被用于简化迭代结构（Martin Flower号称他因此在没有closure的语言中是如此怀念closure），对于从c-style转过来的程序员来说，面对最常使用的each，自然把它看作for, while结构的替代物，所以把return视作从findLine返回，而不是从匿名closure返回是狠自然的。

对此问题，Mike Spille的意见是：一切起因于closure实在太像block，程序员忘记了此处实际上是个语法sugar，本质是个method而并不是一个 block，因而诱导了程序员错误的期望该return的返回位置。既然如此，我们就应该明确哪里是block哪里是closure。其建议就是增加一个指示closure的关键字，譬如def { closure code... }

对此，有人尖锐的指出，那还不如去用C#的delegate！（另一方面，那也是js的实际情况，function关键字就相当于此关键字）

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有