建站
咨詢
售后
建站咨詢
新聞中心
【精選譯文】編者按：在上個(gè)月舉行的Devoxx大會上，Sun宣布Java 7中將包含簡單的閉包特性。這與之前一年Sun的宣布完全相反——當(dāng)時(shí)他們說Java將不會考慮閉包，因?yàn)镴ava不需要。Java社區(qū)對此是有人欣喜有人怒，不過，到底有什么好爭論的呢？一位對C++和Java十分了解，一直關(guān)注編程語言的資深開發(fā)者M(jìn)arek Krj在最近的一篇博文中詳細(xì)的分析了Java需要閉包的理由，并引申C++和C#的一些情況做為自己的論據(jù)。以下是Marek的討論：
#t#多年前，Sun這樣描述微軟對Java的擴(kuò)展提案：
Visual J++的許多優(yōu)點(diǎn)——類型安全、面向?qū)ο?、且易于組件互聯(lián)（component interconnection）——只是對Java對象模型的安全性和靈活性的繼承………
方法綁定（Bound）引用根本沒有必要，它們并不屬于Java編程語言的一個(gè)部分，因此它們也不能被標(biāo)準(zhǔn)的編譯器接受。此外，這些做法會讓Java語言損失掉簡便性和統(tǒng)一性（unity）。
如此等等，這都是些營銷時(shí)所說的胡言亂語。我不知道還有什么比這更惱人的：1.自詡面向?qū)ο蟮恼y(tǒng)地位；2.自滿：“我們更理解Java”。但無論如何，James Gosling（Java之父本人）也很可能會常說他希望閉包（closure）包含在Java中，而不是匿名內(nèi)部類（anonymous inner classes）；3. 對于如何將函數(shù)作為Java語言的頭等公民（first class citiciens）那樣包含進(jìn)去，沒有一個(gè)完整的提案！這就是他們所謂的“根本沒有必要”的論據(jù)……
圍繞著閉包的思想存在著相當(dāng)大的爭議，這有點(diǎn)像我們最近討論過的關(guān)于C++ concepts特性的爭論：人們認(rèn)為它不必要，而且太復(fù)雜了（編者注：作者此處意為今年7月下旬，C++標(biāo)準(zhǔn)委員會確定將concepts特性從C++0x中移除一事。C++編程語言的作者Bjarne Stroustrup為此聲稱C++0x已死，將希望放在新一代C++標(biāo)準(zhǔn)上。）。由于在C++0x中，我們可以使用lambda函數(shù)，這沒引起多少爭議，因此Java社區(qū)對于閉包的這一爭論激起了我的興趣。來啊，為什么不引入閉包呢？甚至C#都包含了一些閉包！
那么，什么是閉包（Closure）呢？在這篇博文中，我們把它認(rèn)為是類似于C++（或Python和Groovy）中l(wèi)ambda那樣的函數(shù)，即一個(gè)匿名的、獨(dú)立式的函數(shù)，比如下面這種：
- auto print = [] (int x) { cout << x; }
現(xiàn)在，讓我們用Java語言來表示這一概念。
1.提案
那么，讓我們來看一看這三個(gè)提案。
a) BGGA(源自Bracha、Gafter、Gosling 和 Ahe的首字母)
這是最雄心勃勃的一個(gè)提案。它引入了一個(gè)新的語言類型：函數(shù)類型，以及它的一個(gè)全新的標(biāo)記方法（notation），這讓我想起了的Haskell或lambda函數(shù)的演算類型（calculus types）：
{T => U} 表示一個(gè)從T到U的函數(shù){T => U => V} (或者這種形式{T,U => V}?) 表示一個(gè)從 T和U到V的函數(shù)
我認(rèn)為，這種標(biāo)記方法是許多Java從業(yè)者不太喜歡此提案的原因之一。另一個(gè)原因顯然歸因于非局部（nonlocal）環(huán)境語句（return ,break等）。新問題再次出現(xiàn)，非局部是指那個(gè)局部？嗯，舉個(gè)例子來說吧，這意味著返回語句將不會從閉包返回，而是從調(diào)用該閉包的區(qū)域內(nèi)返回。它們不是綁定在閉包上，而是綁定在一個(gè)環(huán)境中。為什么這會是一件好事呢？親愛的讀者，下一節(jié)將為您詳細(xì)說明。
一個(gè)使用的例子：
- {Integer => void} print = { Integer x => System.out.println(x); }
b) CICE(簡明實(shí)例創(chuàng)建方式，Concise Instance Creation Expressions)
這是三個(gè)提案中最簡單的一個(gè)。基本上，它只起到在語法上不斷定義匿名類的作用而已，沒有其他的用處。沒有第一類函數(shù)（first class functions）！沒有晦澀難懂的函數(shù)編程理論！
以下是一個(gè)例子：
- public interface IPrint { public void invoke(Integer x);} // exacltly 1 method!
- Print print = IPrint(Integer x) { System.out.println(x); }
雖然CICE是最簡單的提案，但我認(rèn)為它也是最煩人的一個(gè)提案：你必須經(jīng)常返回去查詢一些接口的定義，真是太差勁了！
c) FCM(第一類方法，F(xiàn)irst Class Methods)
這是上面兩個(gè)方案的折衷：它引入了第一類函數(shù)，但其閉包返回語句中并沒有包含非局部綁定，而且去掉了讓人討厭的lambda形式符號。（編者注：FCM是此次Sun宣布通過的提案，詳見Devoxx大會的相關(guān)報(bào)道。不過，作者這篇文章寫于Devoxx之前，當(dāng)時(shí)對此還并不知曉。）
以下是一個(gè)例子：
- #(void(Integer)) print = #(Integer x) { System.out.println(x); }
從以上三類的語法構(gòu)成上來說，我最喜歡的BGGA提案，因?yàn)槟隳軌蛴檬煜さ拇a塊（code-block）方式來編程，而不必使用FCM的hash和CICE的接口標(biāo)簽。
- #(void(Integer)) print = #(Integer x) { System.out.println(x); }
2.爭論
說得客氣一點(diǎn)，我有時(shí)覺得這場辯論有點(diǎn)幼稚。下面是典型的辯點(diǎn)：
◆正方觀點(diǎn)：如果沒有閉包，我將永遠(yuǎn)不會用Java寫哪怕一行代碼，我會轉(zhuǎn)而使用Scala進(jìn)行編程。
◆反方觀點(diǎn)：如果引入閉包，我將會崩潰掉……雖然我不會轉(zhuǎn)向其它語言，但我會因此而怨恨你！
得了吧，各位！只不過是一個(gè)語言的特性而已。如果你不喜歡的話，你不使用它不就得了嗎？而且，選擇什么語言進(jìn)行開發(fā)，是由項(xiàng)目經(jīng)理決定，而不是由開發(fā)人員說了算！如果經(jīng)理們認(rèn)為一個(gè)語言能夠帶來某種好處，那么該語言就有可能被采用。但這與你是否喜歡Scala或其他所謂更好的語言沒有半點(diǎn)的關(guān)系。
那么，閉包是否會使Java變得異常復(fù)雜？閉包是否真的如下面所說的那樣：
“……使編程語言變得復(fù)雜，超過了正常的可用范圍：主流程序員將放棄Java，人們還會繼續(xù)爭論下去，然后會轉(zhuǎn)向使用其它更為簡單的編程語言……
Java會變成一個(gè)只有小范圍內(nèi)的專家才會使用的稀有語言”？
那請你告訴我，對JVM而言什么語言是最簡單的！我找不出最簡單的語言（非腳本語言）。專家語言（Guru language）？你在開玩笑嗎？閉包的目的是讓Java變得更簡單，因此每個(gè)人都應(yīng)該開心才對。為什么要害怕呢？
一個(gè)可能的答案（非PC）是：認(rèn)為“太復(fù)雜”的一方對Java的現(xiàn)狀很滿意，他們不關(guān)注語言優(yōu)雅性的是否缺失，而且不想學(xué)習(xí)新的機(jī)制?；蛟S這是因?yàn)樵谀撤N程度上，Java已經(jīng)存在著太多的機(jī)制（或范型(paradigms)）了？而對我來說，作為一個(gè)使用C++的開發(fā)人員，我已習(xí)慣了“多范型設(shè)計(jì)”，因?yàn)镃++在這方面確實(shí)包羅萬象。我不會去考慮那些我目前使用不到的機(jī)制。
也許，這對Java領(lǐng)域來說并不簡單，因?yàn)槎嗄暌詠鞪ava程序員一直被灌輸一種常識，即世界上只有面向?qū)ο筮@一種范型。這可以解釋人們?yōu)槭裁凑J(rèn)為泛型（generics）的加入會使語言的復(fù)雜性大大增加（另一個(gè)解釋是設(shè)計(jì)選擇上（特別對于通配符）需要考慮向后兼容性）。
因此，事情似乎是這樣：要么是由于人們對泛型機(jī)制的憤怒，要么是由于BGGA提案中包含非局部變量返回這一不常用的做法，激起了人們的強(qiáng)烈反對。你難道不這樣認(rèn)為嗎？
3.討論
讓我們的描述得更加技術(shù)一點(diǎn)：為什么我們在Java里面需要閉包呢？答案很可能是：因?yàn)镽uby語言里面有這個(gè)東西。Java 社區(qū)似乎還集體性的停留在一個(gè)過去Ruby所帶來的創(chuàng)傷，而仿效Ruby的特性在其本身看來理由十分充分。正如過去人們在鐵幕時(shí)期常常說的那樣：學(xué)習(xí)Ruby就是學(xué)習(xí)如何取勝！所以現(xiàn)在，就像在Ruby（或者Groovy和C#）里一樣，我們能夠用Java這樣編程：
- Utils.forEach(names, { Integer x => System.out.println(x); }); // BGGA
而這是我們在帶有STL和lambda庫的C++里面常常使用的東西。
不過，以上的敘述也不是爭論的全部。上述三個(gè)提案中每個(gè)都有第二部分，能夠允許包含某些細(xì)致的資源管理，可以認(rèn)為這是一種“現(xiàn)代的析構(gòu)函數(shù)”。我只能說“最終這樣做了”，因?yàn)镴ava后期的資源管理非常麻煩。
BGGA試圖通過上面提到的非本地控制語句來達(dá)到這個(gè)目標(biāo)，然后可以允許執(zhí)行“execute around”模式，即所謂的“控制抽象化”，但是有些不是很直觀。在BGGA提案里，關(guān)鍵詞是根據(jù)詞匯綁定的，而且會自動指向定義了閉包的嵌套類型（enclosing type）實(shí)例。對我來說，Groovy一定程度上比較清楚的解決了非本地綁定的問題——引進(jìn)了兩個(gè)閉包成員：owner（關(guān)于嵌套對象）和delegate（定義詞匯綁定）。通過這種方式，總是能夠清楚的說明我們需要什么類型的詞匯綁定，delegate的默認(rèn)值是owner。
其他的提案也試圖解決同樣的問題：CICE包含了ARM（自動資源管理模塊 —— 一個(gè)特殊的模塊類型，當(dāng)不使用它的時(shí)候會自動應(yīng)用處理方法），而FCM 包含了JCA（Java控制抽象化 —— 這個(gè)很像上面提到的“execute around“那種類型，而且和BGGA一樣需要非本地的詞匯綁定）。
在這一點(diǎn)上，讓我們試著得出的一些結(jié)論是：
第一：C#的3.0版本里面有l(wèi)ambda，C++0x里面同時(shí)包含有l(wèi)ambda和auto specifier，如果Java 7里再不包含閉包的話，就會顯得十分陳舊了。
但也不要絕望，目前有一個(gè)庫解決方案(http://code.google.com/p/lambdaj/)。在這種情況下，一個(gè)庫解決方案是否足夠呢？我不知道，因?yàn)樗恼Z法看起來不是很直觀，但是它可能已經(jīng)是你能夠得到的最佳方案了。
第二：我發(fā)現(xiàn)此處最有教育意義的內(nèi)容是：我們能夠看到析構(gòu)函數(shù)的老概念其實(shí)一點(diǎn)也不過時(shí)！既然C#有它的使用聲明，那么Java也理應(yīng)（而且需要）包含一些類似于析構(gòu)函數(shù)的機(jī)制。Java這一（前）“現(xiàn)代語言”也需要如此。
原文：Java's Closures Debate for C++ Eyes 作者：Marek Krj
當(dāng)前文章：大辯論：Java不是C++閉包讓Java更簡單
新聞來源：http://m.5511xx.com/article/codcsdc.html
