1. 介紹

本篇是Typing相關知識的最后一篇。介紹關于類型的閉包和類型推斷關系，以及最終的類型靜態編譯相關知識點。

2. 閉包和類型推斷

類型檢查器對閉包執行特殊的推斷，在一邊執行額外的檢查，在另一邊提高流暢性。

2.1 返回類型推斷

類型檢查器能夠做的第一件事是推斷閉包的返回類型。下面的例子簡單地說明了這一點:

@groovy.transform.TypeChecked
int testClosureReturnTypeInference(String arg) {
   def cl = { "Arg: $arg" }       //定義一個閉包，它返回一個GString字符串          
   def val = cl()            //調用閉包并將結果賦值給一個變量                              
val.length()            //類型檢查器推斷閉包將返回一個字符串，因此允許調用length()                                
}

正如上面所看到的，與顯式聲明其返回類型的方法不同，不需要聲明閉包的返回類型:它的類型是從閉包的主體推斷出來的。

2.2 閉包vs方法

返回類型推斷僅適用于閉包。雖然類型檢查器可以對方法執行相同的操作，但實際上并不可取:通常情況下，方法可以被覆蓋，并且靜態地不可能確保所調用的方法不是被覆蓋的版本。所以流類型實際上會認為一個方法返回一些東西，而在現實中，它可以返回其他東西，如下面的例子所示:

@TypeChecked
class A {
   def compute() { 'some string' }      //類A定義了一個方法compute，它返回一個字符串      
   def computeFully() {
compute().toUpperCase()         //這將導致編譯失敗，因為compute的返回類型是def(又名Object)    
  }
}
@TypeChecked
class B extends A {
   def compute() { 123 }         //類B擴展了A并重新定義了compute，該類型返回一個整型              
}

通過上面的示例可以知道，如果類型檢查器依賴于方法的推斷返回類型(使用流類型)，則類型檢查器可以確定是否可以調用toUpperCase?。這實際上是一個錯誤，因為子類可以重寫compute?并返回不同的對象。這里，B.compute?返回一個整型，因此在B?的實例上調用computeFully將會看到一個運行時錯誤。編譯器通過使用方法的聲明返回類型而不是推斷返回類型來防止這種情況發生。

為了保持一致性，這種行為對于每個方法都是相同的，即使它們是靜態的或最終的。

2.3 參數類型推斷

除了返回類型外，閉包還可以從上下文推斷其參數類型。編譯器有兩種方法來推斷形參類型:

• 通過隱式SAM類型強制
• 通過API元數據

讓我們從一個由于類型檢查器無法推斷形參類型而導致編譯失敗的示例開始:

class Person {
String name
   int age
}

void inviteIf(Person p, Closure<Boolean> predicate) {     //inviteIf方法接受一個Person和一個閉包      
   if (predicate.call(p)) {
       // send invite
       // ...
  }
}

@groovy.transform.TypeChecked
void failCompilation() {
Person p = new Person(name: 'Gerard', age: 55)
inviteIf(p) {                                              
it.age >= 18 // No such property: age   它并不是靜態地稱為Person，因此編譯失敗              
  }
}

在這個例子中，閉包體包含了it.age?。對于動態的、非類型檢查的代碼，這是可行的，因為它的類型在運行時是Person?。不幸的是，在編譯時，沒有辦法知道它的類型，只能通過讀取inviteIf的簽名。

2.3.1 顯式閉包參數

簡而言之，類型檢查器在inviteIf?方法上沒有足夠的上下文信息來靜態確定it的類型。這意味著方法調用需要像這樣重寫:

inviteIf(p) { Person it ->          //它的類型需要顯式地聲明                        
it.age >= 18
}

通過顯式聲明it變量的類型，可以解決這個問題，并使此代碼進行靜態檢查。

2.3.2 從單一抽象方法類型推斷出的參數

對于API或框架設計人員來說，有兩種方法可以使其對用戶來說更優雅，這樣他們就不必為閉包參數聲明顯式類型。第一個方法，也是最簡單的方法，是用SAM類型替換閉包:

interface Predicate<On> { boolean apply(On e) }  //使用apply方法聲明SAM接口              

void inviteIf(Person p, Predicate<Person> predicate) {    
   if (predicate.apply(p)) {
       // send invite
       // ...
  }
}

@groovy.transform.TypeChecked
void passesCompilation() {
Person p = new Person(name: 'Gerard', age: 55)

inviteIf(p) {              //不再需要聲明it變量的類型了                                
it.age >= 18          //it.age正確編譯后，它的類型是從Predicate#apply方法簽名推斷出來的                                  
  }
}

通過使用這種技術，我們利用了Groovy將閉包自動強制轉換為SAM類型的特性。

我們應該使用SAM類型還是Closure的問題實際上取決于需要做什么。

在很多情況下，使用SAM接口就足夠了，特別是當考慮Java 8中的功能接口時。

但是，閉包提供了功能接口無法訪問的特性。特別是，閉包可以有一個委托和所有者，并且可以在被調用之前作為對象進行操作(例如，克隆、序列化、curry等等)。它們還可以支持多個簽名(多態性)。

因此，如果需要這種操作，最好切換到下面描述的最高級的類型推斷注釋。

當涉及到閉包參數類型推斷時，最初需要解決的問題是，Groovy類型系統繼承了Java類型系統，而Java類型系統不足以描述參數的類型，也就是說，靜態地確定閉包的參數類型，而無需顯式地聲明它們。

2.3.3 使用@ClosureParams 注解

Groovy提供了一個注解@ClosureParams，用于完成類型信息。該注釋主要針對那些希望通過提供類型推斷元數據來擴展類型檢查器功能的框架和API開發人員。如果我們的庫使用閉包，并且也希望獲得最大級別的工具支持，那么這一點非常重要。

讓我們通過修改原始示例來說明這一點，引入@ClosureParams注釋:

import groovy.transform.stc.ClosureParams
import groovy.transform.stc.FirstParam
void inviteIf(Person p, @ClosureParams(FirstParam) Closure<Boolean> predicate) {   //閉包參數用@ClosureParams注釋    
   if (predicate.call(p)) {
       // send invite
       // ...
  }
}
inviteIf(p) {                                                                      
it.age >= 18  //沒有必要為它使用顯式類型，因為它是推斷出來的
}

@ClosureParams?注釋最少接受一個參數，該參數被命名為類型提示。類型提示是一個類，它負責在閉包的編譯時完成類型信息。在本例中，使用的類型提示是groovy.transform.stc.FirstParam?，它向類型檢查器指示閉包將接受一個類型為方法第一個參數類型的參數。在本例中，方法的第一個參數是Person?，因此它向類型檢查器指示閉包的第一個參數實際上是Person。

第二個可選參數名為options。它的語義取決于類型提示類。Groovy提供了各種捆綁的類型提示，如下表所示:

即使你使用FirstParam?, SecondParam或ThirdParam作為類型提示，這并不嚴格意味著將傳遞給閉包的參數將是第一個(resp。方法調用的第二個，第三個)參數。這只意味著閉包的參數類型將與第一個(resp。方法調用的第二個，第三個)參數。

PS: 上面的表格，從Groovy中直接賦值的。所以表格閱讀比較難看

簡而言之，在接受Closure?的方法上缺少@ClosureParams注釋不會導致編譯失敗。如果存在(它可以出現在Java源代碼中，也可以出現在Groovy源代碼中)，則類型檢查器具有更多信息，并可以執行額外的類型推斷。這使得框架開發人員對該特性特別感興趣。

第三個可選參數名為conflictResolutionStrategy。它可以引用一個類(從

ClosureSignatureConflictResolver擴展而來)，如果在初始推斷計算完成后發現了多個參數類型，則該類可以執行額外的參數類型解析。Groovy提供了一個默認類型解析器，它什么都不做，另一個則在找到多個簽名時選擇第一個簽名。解析器僅在發現多個簽名時調用，并且被設計為后處理器。任何需要注入類型信息的語句都必須傳遞一個通過類型提示確定的參數簽名。解析器然后從返回的候選簽名中選擇。

類型檢查器使用@DelegatesTo?注釋推斷委托的類型。它允許API設計者指示編譯器委托的類型和委托策略。@DelegatesTo注釋將在其他內容中進行專門的討論。這里就不擴展了。

3. 靜態編譯

3.1 動態與靜態

在類型檢查部分，我們已經看到Groovy通過@TypeChecked?注釋提供了可選的類型檢查。類型檢查器在編譯時運行，并對動態代碼執行靜態分析。無論是否啟用類型檢查，程序的行為都完全相同。這意味著@TypeChecked注釋對于程序的語義是中立的。盡管可能有必要在源中添加類型信息以使程序被認為是類型安全的，但最終，程序的語義是相同的。

雖然這聽起來很好，但實際上有一個問題:在編譯時執行的動態代碼的類型檢查，根據定義，只有在沒有發生特定于運行時的行為時才正確。例如，下面的程序通過了類型檢查:

class Computer {
   int compute(String str) {
str.length()
  }
String compute(int x) {
String.valueOf(x)
  }
}

@groovy.transform.TypeChecked
void test() {
   def computer = new Computer()
computer.with {
       assert compute(compute('foobar')) =='6'
  }
}

有兩種計算方法。一個接受String?并返回int?，另一個接受int?并返回String?。如果你編譯這個，它被認為是類型安全的:內部compute('foobar')?調用將返回一個int?，并且在這個int?上調用compute?將返回一個String。

現在，在調用test()之前，考慮添加以下行:

Computer.metaClass.compute = { String str -> new Date() }

使用運行時編程，我們實際上是在修改compute(String)?方法的行為，這樣它就不會返回所提供的參數的長度，而是返回一個Date。如果執行該程序，它將在運行時失敗。因為這一行可以在任何線程的任何地方添加，所以類型檢查器絕對沒有辦法靜態地確保沒有這樣的事情發生。簡而言之，類型檢查器很容易受到猴子修補的攻擊。這只是一個例子，但它說明了對動態程序進行靜態分析本質上是錯誤的。

Groovy為@typecheck?提供了另一種注釋，它實際上將確保被推斷為被調用的方法將在運行時有效地被調用。該注釋將Groovy編譯器轉換為靜態編譯器，其中所有方法調用都在編譯時解析，生成的字節碼確保實現這一點:注釋是@groovy.transform.CompileStatic。

3.2 @CompileStatic 注解

@CompileStatic?注釋可以添加到@TypeChecked?注釋可以使用的任何地方，也就是說，在類或方法上。沒有必要同時添加@TypeChecked和@CompileStatic?，因為@CompileStatic?執行@TypeChecked所做的一切，但是還會觸發靜態編譯。

讓我們以失敗的例子為例，但這一次讓我們用@CompileStatic?替換@TypeChecked注釋:

class Computer {
    int compute(String str) {
        str.length()
    }
    String compute(int x) {
        String.valueOf(x)
    }
}

@groovy.transform.CompileStatic
void test() {
    def computer = new Computer()
    computer.with {
        assert compute(compute('foobar')) =='6'
    }
}
Computer.metaClass.compute = { String str -> new Date() }
test()

這是唯一的區別。如果我們執行這個程序，這次就不會出現運行時錯誤。test?方法不再受猴子補丁的影響，因為在它的主體中調用的計算方法在編譯時是鏈接的，所以即使Computer的元類發生了變化，程序仍然按照類型檢查器的預期行事。

3.3 關鍵優勢

在代碼中使用@CompileStatic有幾個好處:

• 類型安全
• 對猴子補丁(monkey patching)免疫
• 性能改進

性能的提高取決于所執行程序的類型。

如果它受I/O限制，靜態編譯代碼和動態代碼之間的區別幾乎不明顯。

對于高度CPU密集型的代碼，由于生成的字節碼與Java為等效程序生成的字節碼非常接近(如果不是相等的話)，因此性能得到了極大的提高。

4. 小結

到這里關于類型的相關知識就介紹完畢了，以上內容可以通過Groovy官方文檔：Groovy Language Documentation (groovy-lang.org)了解更多知識。

PS：類型知識的介紹更多的是從各種概念定義等方面詳細介紹各種類型推斷的過程。我們其實可以簡單了解。