分享
 
 
 

New Groovy --- Closure/Block问题

王朝java/jsp·作者佚名  2006-01-09
窄屏简体版  字體: |||超大  

在经历了从blog到mailing list的腥风血雨之后,New Groovy的Roadmap粉墨登场。一定程度上这是对最近一段时间尘嚣甚上的Groovy is dead的回应。另一方面,Groovy的苦谏者Mike Spille对于新Groovy特性的批评所得到的回应却是以wiki形式确定下来的文档

所有新特性中争议最大的,当然就是此条: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的关系,我尚无力作出论断。先走着瞧吧……

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有