語言總會演化,過程中開發者總希望增添自己喜愛的特性,他們經常嚷嚷「為何不加入X?」,在鵠首企昐的特性加入語言後,開發者又叫囂著「這什麼鬼東西?」

從使用者角度來看,語言特性越多越好,特性彼此間像是互不侵擾;從語言本身來看,要加入任何新特性幾乎都沒問題,然而新舊特性間的侵擾會造成複雜度的提升。有時,認識語言演化過程是必要的,以瞭解語言為何有目前樣貌,善用新特性的良好部份,並避開新的複雜性。

維持現有語法及API相容性
近幾年來,一級函式的應用受到重視,連不算年輕的Java也打算加入此一特性,長久以來Java不存在一級函式,觀察Lambda規格JSR335的演化過程,可作為認識語言演化考量的實際案例。

在動態語言如JavaScript、Python,一級函式是重要且經常應用的特性,因為無論是建立一級函式,或是宣告能接受一級函式的變數,都不用指定型態,使用一級函式對程式碼表述力有助益;對靜態語言來說,一級函式主要問題在於型態為何?舉例來說,Scala視參數個數而定,一級函式會是Function、Function1、Function2等函數型態(Function type)實例,有專屬型態系統。如果方法(或函式)可接受函式,參數就必須宣告對應的型態。

在Lambda最初草案中,Java原本預計採用類似Scala的作法,為一級函式制訂專屬函式型態,在不與現有關鍵字衝突的考量下,使用了#int(int, int) sum = #(int x, int y)(x + y)的語法,新語法問題之一是不一致,#int(int, int)傳回值宣告在左邊,而Lambda語法函式本體是在右邊,這也造成另一問題,從函式中傳回函式是一級函式常見應用,如果有函式接受一個int然後傳回新函式,新函式接受一個int並傳回int,那麼型態宣告就會是##int(int)(int),這讓人彷彿看到,泛型語法造成Enum>之類的遞迴性問題。

另一問題在於Java長久累積的龐大程式庫,如果為了Lambda建立專屬型態,那麼,現有程式庫就無法在新語法上,得到任何助益,你得建立一套新API,在接受函式的方法上宣告函式型態。

即使能找到一個途徑,讓函式型態可像泛型語法得到向後相容性,升級現有API也會是個龐大工程,想想泛型語法出現後多久才獲得採用,就可得知。因為這是在修改公開介面,而且勢必在已經夠複雜的方法宣告上,加入更複雜語法。

Java最後採取了函式介面(Functional interface),這類僅具單一抽象方法的介面遍佈現有程式庫之中;Lambda運算式語法獨立於型態之外,同一Lambda運算式,會因目標函式介面不同,而為不同實例,避免了為Lambda運算式制訂專屬型態問題。為了能重用現有API,使用了方法參考(Method reference),只要現有方法的簽署符合函式介面的方法簽署(名稱除外),就可以直接包裹為目標實例,不用撰寫新的Lambda運算式。

統一風格與避免複雜度

引入語言新特性時,除了避免引入新複雜度外,讓新特性看來像是原有語言的一部份,而不是突兀的方言也是個目標。除了讓新語法相容於現有API,如果想增加一套與新特性搭配的API,也得有相同考量。

以Java來說,既然有了Lambda語法,自然就會想到伴隨著Lambda語法而存在的函數式風格程式庫。問題重點在於,這些新API要定義在哪?函數式語言特別擅長處理資料,因而Java考量是否建立新的Collection2來取代現有Collection框架,不過,Collection的應用貫穿了現有應用程式與程式庫,是個考量,單為了Lambda建立新的Collection2工作太過龐大,無法成為下個版本JDK8的目標。

那麼,直接新增在Collections上成為靜態方法呢?像是guava-libraries在Iterables與Iterators上提供的那些靜態方法?結果很明顯,這會讓你覺得使用guava-libraries風格撰寫程式,也就是這種作法,會讓新API看來不像是Java原有風格。

Java以物件導向為主流典範,Lambda應用概念則來自函數式語言,對於適切融合函數式與物件導向,Scala是成功案例,借鏡而來的作法是在Collection介面上增加方法——這是大問題,因為在介面增加方法,意謂著所有實作類別都得實現,以Collection為基礎的程式太多,不可採取這種破壞式的作法。

有許多防禦式(Defensive)的API演化方式,可以讓你在演化介面時,避免影響介面的使用者,像是提供預設實作以避免使用者直接實作介面,不過這些方式,得在一開始就作好設計。

Java的作法是解除介面限制,讓它可擁有防禦者方法(Defender method),而不僅能定義抽象方法。防禦者方法就是允許在介面中有條件實作的預設方法(Default method),這有點像是作弊,因為只有語言制定者,才能作這種防禦式介面演化,不過,這確實也為日後的防禦式介面演化,提供更大彈性。

相對防禦式介面演化的是侵犯式(Offensive)介面演化,後者是不管使用者直接演化介面,使用者在升級前須修改程式,因而有遭侵犯的感覺。

侵犯式演化若過於劇烈,使用者就不願意或緩慢採納,Python3是個案例,由於語法變異過大,許多現有程式庫多半觀望而不願升級。Java解開介面限制也有代價,最直接的衝擊就是使函式介面的判斷變複雜,這後來提出了@FunctionalInterface並結合編譯器協助判斷,另一問題在於實作介面就是多重繼承,以往為了限制複雜度,因而不允許介面擁有實作方法,一旦解開此限制,在可繼承實作情況下,必然帶入多重繼承的複雜問題。

作法明確而不是隱含
有別於使用iterator方法傳回外部迭代(External iteration)用的Iterator實例,JDK8在Collection上增加內部迭代(Internal iteration)的方法,像是forEach、map、filter、reduce等,內部迭代令程式庫可以掌控迭代流程,使得延遲性(Laziness)、平行化等非循序性實作細節得以隱藏,然而,使用者如何知道何時操作有延遲性?何時以平行化操作?

Java語言演化原則之一,是程式碼閱讀比撰寫重要。在觀察許多Collection迴圈操作之後,發現許多中介運算都可有延遲性,最後取得結果時才需要立即的(Eager)操作。

JDK8定義Stream介面負責中介(Intermediate)操作,Collection介面上新增了stream方法傳回Stream實例,Stream的map、filter等只要傳回Stream實例的方法,都是中介操作,其他如forEach、reduce不傳回Stream實例的都是結束(Terminal)操作,這也使Collection不因塞入map、filter等方法而肩負太多職責。然而,會產生shapes.stream(..).filter(..).collect(..)這類操作,不少人覺得stream方法降低簡潔性,簡潔是個優點,然而語言不能隱藏發生的事,明確而非隱含是此一設計的目的。

瞭解新特性與複雜度間的平衡點
找出新特性與複雜度的平衡點很困難,這是制訂語言者的責任,不過絕非多數使用者的天真想法:「喔!增加個X很簡單,不會太複雜!」Joshua Bloch後來面對泛型也只能說,面對複雜性與功能時,須想得更透徹,若語言已逼近使用者理解能力,你不可能在不搞爛它的情況下,加入任何複雜性。

Joshua Bloch亦以C++為例,複雜並沒有使C++消失,只是令使用者取用功能子集。因而,身為使用者,得瞭解新特性與複雜度間的平衡點,在使用新特性時若覺得太複雜時,才能適時地考慮採用新特性的子集,就像使用泛型確實有其優點,然而如果情況變得複雜,也得有所取捨或作其他設計考量。

作者簡介


Advertisement

更多 iThome相關內容