1. 介紹

在上一篇介紹了基本的Groovy的類型檢查擴(kuò)展，以及該擴(kuò)展的意義和部分的API說(shuō)明。

本篇接著上篇沒(méi)有講完的內(nèi)容，繼續(xù)介紹類型檢查擴(kuò)展的相關(guān)知識(shí)點(diǎn)。

2. 使用類型檢查擴(kuò)展

我們講解了如何創(chuàng)建類型檢查擴(kuò)展，這里開(kāi)始講解各種的使用方式。

2.1 支持類-Support classes

DSL依賴于一個(gè)名為org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport的支持類。這個(gè)類本身擴(kuò)展了org.codehaus.groovy.transform.stc.TypeCheckingExtension。這兩個(gè)類定義了許多幫助器方法，使使用AST變得更容易，特別是在類型檢查方面。要知道的一件有趣的事情是，我們可以訪問(wèn)類型檢查器。這意味著我們可以以編程方式調(diào)用類型檢查器的方法，包括那些允許拋出編譯錯(cuò)誤的方法。

擴(kuò)展腳本委托給org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport類，這意味著我們可以直接訪問(wèn)以下變量:

• context：類型檢查器上下文，類型為org.codehaus.groovy.transform.stc.TypeCheckingContext
• typeCheckingVisitor：類型檢查器本身，一個(gè)org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor實(shí)例
• generatedMethods：一個(gè)“生成方法”的列表，這實(shí)際上是一個(gè)“dummy”方法的列表，你可以使用newMethod調(diào)用在一個(gè)類型檢查擴(kuò)展中創(chuàng)建。

類型檢查上下文包含大量在上下文中對(duì)類型檢查器有用的信息。例如，當(dāng)前的封閉方法調(diào)用堆棧、二進(jìn)制表達(dá)式、閉包等等，如果我們必須知道錯(cuò)誤發(fā)生時(shí)我們?cè)谀睦镆约拔覀兿胍幚硭敲催@些信息就特別重要。

除了GroovyTypeCheckingExtensionSupport和StaticTypeCheckingVisitor提供的功能外，類型檢查DSL腳本還從org.codehaus.groovy.ast.ClassHelper和org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport導(dǎo)入靜態(tài)成員，允許通過(guò)OBJECT_TYPE、STRING_TYPE、THROWABLE_TYPE等對(duì)公共類型進(jìn)行訪問(wèn)，并檢查諸如missesgenericsttypes(ClassNode)、isClassClassNodeWrappingConcreteType(ClassNode)等。

2.2 類節(jié)點(diǎn)-Class nodes

在使用類型檢查擴(kuò)展時(shí)，需要特別注意處理類節(jié)點(diǎn)。編譯使用抽象語(yǔ)法樹(shù)(AST)，當(dāng)您檢查類的類型時(shí)，該樹(shù)可能不完整。這也意味著在引用類型時(shí)，不能使用String或HashSet等類字面量，而是使用表示這些類型的類節(jié)點(diǎn)。這需要一定程度的抽象和理解Groovy如何處理類節(jié)點(diǎn)。為了簡(jiǎn)化工作，Groovy提供了幾個(gè)輔助方法來(lái)處理類節(jié)點(diǎn)。例如，如果你想說(shuō)“String的類型”，你可以這樣寫(xiě):

assert classNodeFor(String) instanceof ClassNode

還會(huì)注意到，classNodeFor有一個(gè)變體，它以String而不是Class作為參數(shù)。一般來(lái)說(shuō)，我們不應(yīng)該使用該方法，因?yàn)樗鼘?chuàng)建一個(gè)名稱為String的類節(jié)點(diǎn)，但沒(méi)有在其上定義任何方法、任何屬性等。第一個(gè)版本返回已解析的類節(jié)點(diǎn)，而第二個(gè)版本返回未解析的類節(jié)點(diǎn)。所以后者應(yīng)該留給非常特殊的情況。

可能遇到的第二個(gè)問(wèn)題是引用一個(gè)尚未編譯的類型。這種情況發(fā)生的頻率可能比你想象的要高。例如，當(dāng)一起編譯一組文件時(shí)。在這種情況下，如果你想說(shuō)“那個(gè)變量是Foo類型的”，但Foo還沒(méi)有編譯，仍然可以使用lookupClassNodeFor引用Foo類節(jié)點(diǎn):

assert lookupClassNodeFor('Foo') instanceof ClassNode

2.3 類型檢查器的幫助

假設(shè)你知道變量foo的類型是Foo，你想告訴類型檢查器。然后可以使用storeType方法，該方法接受兩個(gè)參數(shù):第一個(gè)參數(shù)是希望存儲(chǔ)類型的節(jié)點(diǎn)，第二個(gè)參數(shù)是節(jié)點(diǎn)的類型。如果查看storeType的實(shí)現(xiàn)，我們將看到它委托給類型檢查器等效方法，該方法本身做了大量工作來(lái)存儲(chǔ)節(jié)點(diǎn)元數(shù)據(jù)。還將看到，存儲(chǔ)類型并不局限于變量:可以設(shè)置任何表達(dá)式的類型。

同樣，獲取AST節(jié)點(diǎn)的類型只需調(diào)用該節(jié)點(diǎn)上的getType即可。這通常是你想要的，但有一些注意事項(xiàng):

1. getType返回一個(gè)表達(dá)式的推斷類型。這意味著對(duì)于聲明為Object類型的變量，它不會(huì)返回Object的類節(jié)點(diǎn)，而是在代碼的這一點(diǎn)返回該變量的推斷類型(流類型)。
2. 如果想訪問(wèn)變量(或字段/參數(shù))的原始類型，那么必須在AST節(jié)點(diǎn)上調(diào)用適當(dāng)?shù)姆椒ā?/li>

2.4 拋出錯(cuò)誤

要拋出一個(gè)類型檢查錯(cuò)誤，你只需要調(diào)用addStaticTypeError方法，它有兩個(gè)參數(shù):

• 將顯示給最終用戶的字符串形式的消息
• 負(fù)責(zé)錯(cuò)誤的AST節(jié)點(diǎn)。最好提供最合適的AST節(jié)點(diǎn)，因?yàn)樗鼘⒂糜跈z索行號(hào)和列號(hào)

2.5 isXXXExpression表達(dá)式

通常需要知道AST節(jié)點(diǎn)的類型。為了可讀性DSL提供了一個(gè)特殊的isXXXExpression方法，該方法將委托給XXXExpression的x實(shí)例。例如:

不建議的寫(xiě)法:

if (node instanceof BinaryExpression) {
  ...
}

正確，推薦的寫(xiě)法:

if (isBinaryExpression(node)) {   ... }

2.6 虛擬方法-Virtual methods

當(dāng)我們執(zhí)行動(dòng)態(tài)代碼的類型檢查時(shí)，可能經(jīng)常會(huì)遇到這樣的情況:知道一個(gè)方法調(diào)用是有效的，但它背后并沒(méi)有“真正的”方法。

以Grails動(dòng)態(tài)查找器為例。可以有一個(gè)由名為findByName(…)的方法組成的方法調(diào)用。

由于bean中沒(méi)有定義findByName方法，類型檢查器會(huì)報(bào)錯(cuò)。

但是，我們知道這個(gè)方法在運(yùn)行時(shí)不會(huì)失敗，甚至可以知道這個(gè)方法的返回類型是什么。

對(duì)于這種情況，DSL支持由虛擬方法組成的兩個(gè)特殊構(gòu)造。這意味著將返回一個(gè)實(shí)際上并不存在但在類型檢查上下文中定義的方法節(jié)點(diǎn)。有三種方法:

• newMethod(String name, Class returnType)
• newMethod(String name, ClassNode returnType)
• newMethod(String name, Callable<ClassNode> return Type)

所有這三個(gè)方法都做同樣的事情:它們創(chuàng)建一個(gè)新的方法節(jié)點(diǎn)，其名稱是提供的名稱，并定義該方法的返回類型。

此外，類型檢查器會(huì)將這些方法添加到generatedMethods列表中。我們只設(shè)置名稱和返回類型的原因是，這是在90%的情況下所需要的。

例如，在上面的findByName示例中，只需要知道findByName不會(huì)在運(yùn)行時(shí)失敗，并且它返回一個(gè)域類。

返回類型的Callable版本很有趣，因?yàn)楫?dāng)類型檢查器實(shí)際需要返回類型時(shí)，它推遲了返回類型的計(jì)算。

在某些情況下，當(dāng)類型檢查器要求返回類型時(shí)，可能不知道實(shí)際的返回類型，因此可以使用閉包，每當(dāng)類型檢查器在此方法節(jié)點(diǎn)上調(diào)用getReturnType時(shí)，都會(huì)調(diào)用閉包。

如果將此與延遲檢查結(jié)合起來(lái)，就可以實(shí)現(xiàn)相當(dāng)復(fù)雜的類型檢查，包括前向引用的處理。

newMethod(name) {
   //每次調(diào)用這個(gè)方法節(jié)點(diǎn)上的getReturnType時(shí)，這個(gè)閉包就會(huì)被調(diào)用!
println 'Type checker called me!'
lookupClassNodeFor(Foo) //返回類型
}

如果你需要的不僅僅是名稱和返回類型，你可以自己創(chuàng)建一個(gè)新的MethodNode。

2.7 范圍-Scoping

范圍在DSL類型檢查中非常重要，這也是為什么我們不能使用基于切入點(diǎn)的方法來(lái)進(jìn)行DSL類型檢查的原因之一。

基本上，必須能夠非常精確地定義何時(shí)應(yīng)用擴(kuò)展，何時(shí)不應(yīng)用擴(kuò)展。此外，必須能夠處理常規(guī)類型檢查器無(wú)法處理的情況，例如前向引用:

point a(1,1)
line a,b // b是事后引用的!
point b(5,2)

例如，你想處理一個(gè)構(gòu)建器:

builder.foo {
 bar
 baz(bar)
}

因此，我們的擴(kuò)展應(yīng)該只在輸入foo方法時(shí)是活動(dòng)的，并且在此范圍之外是不活動(dòng)的。

但是，可能會(huì)遇到復(fù)雜的情況，比如同一個(gè)文件中有多個(gè)構(gòu)建程序或嵌入式構(gòu)建程序(構(gòu)建程序中的構(gòu)建程序)。

雖然不應(yīng)該嘗試從一開(kāi)始就修復(fù)所有這些問(wèn)題(必須接受類型檢查的限制)，但類型檢查器確實(shí)提供了一種很好的機(jī)制來(lái)處理這個(gè)問(wèn)題:使用newScope和scopeExit方法的作用域堆棧。

• newScope ：創(chuàng)建一個(gè)新的作用域并將其放在堆棧頂部
• scopeExits ：從堆棧中彈出作用域

范圍包括:

• 父作用域
• 自定義數(shù)據(jù)的Map

如果想看一下實(shí)現(xiàn)，它只是一個(gè)LinkedHashMap (org.codehaus.groovytypecheckingextensionsupport.typecheckingscope)，但是它非常強(qiáng)大。例如，可以使用這樣的作用域來(lái)存儲(chǔ)退出作用域時(shí)要執(zhí)行的閉包列表。這是處理前向引用的方式:

def scope = newScope()
scope.secondPassChecks = []
//...
scope.secondPassChecks << { println 'executed later' }
// ...
scopeExit {
secondPassChecks*.run() // 執(zhí)行延遲檢查
}

也就是說(shuō)，如果在某個(gè)時(shí)候無(wú)法確定表達(dá)式的類型，或者此時(shí)無(wú)法檢查賦值是否有效，仍然可以稍后進(jìn)行檢查……這是一個(gè)非常強(qiáng)大的功能。

現(xiàn)在，newScope和scopeExit提供了一些有趣的語(yǔ)法糖:

newScope {
    secondPassChecks = []
}

在DSL中的任何時(shí)候，都可以使用getCurrentScope()或更簡(jiǎn)單的currentScope訪問(wèn)當(dāng)前作用域:

//...
currentScope.secondPassChecks << { println 'executed later' }
// ...

一般的模式是:

• 確定將新作用域推入堆棧的切入點(diǎn)，并在此作用域中初始化自定義變量
• 使用各種事件，可以使用存儲(chǔ)在自定義范圍中的信息來(lái)執(zhí)行檢查、延遲檢查……
• 確定退出范圍的切入點(diǎn)，調(diào)用scopeExit并最終執(zhí)行額外的檢查

2.8 其他有用的方法

要獲得helper方法的完整列表，請(qǐng)參考類org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport和類org.codehaus.groovy.transform.stc.TypeCheckingExtension。但是，要特別注意以下方法:

• isDynamic: 接受VariableExpression作為參數(shù)，如果變量是DynamicExpression則返回true，這意味著在腳本中，它不是使用類型或def定義的。
• isGenerated:接受MethodNode作為參數(shù)，并告知該方法是否是由類型檢查器擴(kuò)展使用newMethod 方法生成的方法
• isAnnotatedBy: 接受一個(gè)AST節(jié)點(diǎn)和一個(gè)類(或ClassNode)，并告知該節(jié)點(diǎn)是否用這個(gè)類標(biāo)注。例如: isAnnotatedBy(node, NotNull)
• getTargetMethod: 接受一個(gè)方法調(diào)用作為參數(shù)，并返回類型檢查器為其確定的 MethodNode
• delegatesTo: 模擬@DelegatesTo注解的行為。它允許我們判斷參數(shù)將委托給特定類型(也可以指定委托策略)

3. 小結(jié)

關(guān)于類型檢測(cè)擴(kuò)展的使用相關(guān)知識(shí)要點(diǎn)，就介紹到這里了。以上相關(guān)內(nèi)容可以參考Groovy官方文檔：http://docs.groovy-lang.org/docs/groovy-4.0.6/html/documentation/#Typecheckingextensions-Workingwithextensions進(jìn)行查詢。