所有新特性中争议最大的,当然就是此条: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关键字就相当于此关键字)
无论如何,情况很清楚:普通block和closure在syntax上如此相似以至于无法分辨,解决方案无外乎,区分它们(Mike Spille的建议),或者统一它们——使得break/return等的语义在block和closure中一致!
John Rose提出的并且为多数人接受的方案是,应该令closure的return如程序员最可能期望的那样行为:返回到定义其的函数上。并且他还参照 smalltalk, ruby, lisp等提出了break, continue在closure中的一揽子改进语法和语义。由此,通过在closure中使用continue L:value的语法结构,可以达到从label L处返回value的需求。(当然实际需要使用这样怪异的continue的机会其实很少,按照我一贯的语调——你当然可以用xxx,但是如果需要用到 xxx,那往往是坏味道的信号……)
对此提案,Mike Spille自然是全力反对,对此的指责还牵涉上了开发进度、管理模式等问题。如我没有看错,Mike Spille的rant(虽然他自己不承认)甚至多次要求几个核心人物下台……:D
顺便说一下,在我写前面那个mail的时候,还没有意识到这个问题。John Wilson的re中向我指出了这个棘手问题:
On 16 Jan 2005, at 13:53, Shijun He wrote: > 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. > this is almost true but not quite.. if (a == 1) { return // returns from enclosing function } a.each { return // returns from closure } this (and break in a closure) catches people out a lot. This has been discussed a great deal but we have not come up with a solution which pleases everybody.
显然,要pleases everybody是mission impossible :( 事实上吵的天翻地覆……Mike Spille已经被冠以FUD的名号了。
最近几天,我也跟pt同志讨论了这个问题,并且还拉出了ruby和lisp/scheme来“寻根”。pt同志的意见与Mike Spille出奇的一致。pt坚持认为closure就应该是function,改变return的语义是不可接受的。但是ruby的现状却是更接近 John Rose所说的(至少匿名closure的return不返回closure本身而返回到上层函数)。如果我们不怀疑John Rose的专业水准(这点倒是连Mike Spille也承认的,John是个有多种语言经验的高手),那么closure的这种return语义,是Smalltalk的语言标准规定的,而 ruby有大量的概念是师从smalltalk的,closure应该也不例外。进一步的,连Groovy的主要设计者James Strachan都发话了:我们不是要改变什么,而是要把从来没有明确下来的return/break/continue的语义明确下来,是要把尚未完全实现的closure功能完全化。(我乱说一句:这个有马后炮之嫌:))。
问题最后进入了“哲学”阶段(请千万不要误会我是在调侃哲学)。那就是“什么是closure”。显然,目前为止我更相信John Rose的说法,lisp以来的closure都是如此,即一种特殊的block结构体。连Mike Spille的许多议论也只是说,groovy的目标是java程序员,应此不必全盘“西化”,应首先考虑java程序员的接受程度,譬如 closure/block的统一会破坏对java程序结构的认识根基。(不过此点在我看了'Java中的closure'这篇奇闻逸事之后,就根本不能说服我了。)
common lisp,具有特殊的操作符就叫做block,还有return-from,可以return到任何指定的层级!可谓是超级彻底的block!!另一方面,pt强烈认为closure就是lambda,或者说是lambda在命令式语言(OO语言?)中的复制品。他还认为跳转到上级lex应该以 call/cc方式实现。俺对lisp/scheme所知甚少,也不可能想清楚这当子事情。不过至少有一点是清楚的:Groovy的选择已经作出,并且我也觉得这是符合其核心价值的。至于其与block, func, method的关系,我尚无力作出论断。先走着瞧吧……