Groovy 類型檢查擴(kuò)展，編寫類型檢查擴(kuò)展

作者：Zinyan 2023-01-05 08:09:27

Groovy是實(shí)現(xiàn)內(nèi)部DSL?的首選平臺(tái)。靈活的語(yǔ)法，結(jié)合運(yùn)行時(shí)和編譯時(shí)元編程功能，使Groovy成為一個(gè)有趣的選擇，因?yàn)樗试S程序員專注于DSL?，而不是工具或?qū)崿F(xiàn)。由于Groovy DSL是Groovy代碼，因此很容易獲得IDE工具的支持，而不必編寫專門的插件。

1. 介紹

本篇Groovy學(xué)習(xí)筆記第37篇。開(kāi)始介紹Groovy中的擴(kuò)展類型檢查相關(guān)知識(shí)。學(xué)會(huì)如何定義我們的類型檢查器。

在前面分享的關(guān)于類型知識(shí)，更多的是依靠Groovy中的靜態(tài)類型檢查器實(shí)現(xiàn)的。

而本篇開(kāi)始要介紹的就是定義我們自己的類型檢查。也就叫做類型檢查擴(kuò)展，定義自己的類型檢查器。

類型檢查擴(kuò)展是一種機(jī)制，它允許DSL引擎的開(kāi)發(fā)人員對(duì)常規(guī)groovy類應(yīng)用靜態(tài)類型檢查所允許的相同類型的檢查，從而使這些腳本更加安全。

PS：總的來(lái)說(shuō)，類型檢測(cè)擴(kuò)展的相關(guān)知識(shí)，可能更多的適合于采用Groovy進(jìn)行插件開(kāi)發(fā)的工程師使用。用于檢測(cè)定義的DSL腳本是否合規(guī)等。

2. 編寫類型檢查擴(kuò)展

下面來(lái)介紹，如何編寫我們的類型檢查。

2.1 智能的類型檢查器

Groovy可以在編譯時(shí)與靜態(tài)類型檢查器一起使用，使用@TypeChecked注解啟用。在這種模式下，編譯器會(huì)變得更加冗長(zhǎng)，并拋出錯(cuò)誤，例如拼寫錯(cuò)誤、不存在的方法等。不過(guò)，這也帶來(lái)了一些限制，其中大多數(shù)限制來(lái)自Groovy本質(zhì)上仍然是一種動(dòng)態(tài)語(yǔ)言。例如，你不能在使用標(biāo)記構(gòu)建器的代碼上使用類型檢查:

def builder = new MarkupBuilder(out)
builder.html {
head {
       // ...
  }
body {
p 'Hello, world!'
  }
}

在上面的例子中，html、head、body或p方法都不存在。但是，如果執(zhí)行代碼，它可以工作，因?yàn)镚roovy使用動(dòng)態(tài)分派并在運(yùn)行時(shí)轉(zhuǎn)換這些方法調(diào)用。在這個(gè)構(gòu)建器中，我們可以使用的標(biāo)記數(shù)量和屬性都沒(méi)有限制，這意味著類型檢查器沒(méi)有機(jī)會(huì)在編譯時(shí)知道所有可能的方法(標(biāo)記)，除非我們創(chuàng)建一個(gè)專用于HTML的構(gòu)建器。

Groovy是實(shí)現(xiàn)內(nèi)部DSL的首選平臺(tái)。靈活的語(yǔ)法，結(jié)合運(yùn)行時(shí)和編譯時(shí)元編程功能，使Groovy成為一個(gè)有趣的選擇，因?yàn)樗试S程序員專注于DSL，而不是工具或?qū)崿F(xiàn)。由于Groovy DSL是Groovy代碼，因此很容易獲得IDE工具的支持，而不必編寫專門的插件。

在很多情況下，DSL引擎是用Groovy(或Java)編寫的，然后用戶代碼作為腳本執(zhí)行，這意味著在用戶邏輯之上有某種包裝器。例如，包裝器可能包含在GroovyShell或GroovyScriptEngine中，它們?cè)谶\(yùn)行腳本之前透明地執(zhí)行一些任務(wù)(添加導(dǎo)入、應(yīng)用AST轉(zhuǎn)換、擴(kuò)展基本腳本等等)。通常，用戶編寫的腳本無(wú)需測(cè)試就可以投入生產(chǎn)，因?yàn)镈SL邏輯達(dá)到了任何用戶都可以使用DSL語(yǔ)法編寫代碼的地步。最后，用戶可能會(huì)忽略他們所編寫的實(shí)際上是代碼。這為DSL實(shí)現(xiàn)者增加了一些挑戰(zhàn)，例如確保用戶代碼的執(zhí)行，或者在這種情況下，及早報(bào)告錯(cuò)誤。

例如，想象一個(gè)DSL：其目標(biāo)是遠(yuǎn)程駕駛火星上的漫游者。向探測(cè)器發(fā)送信息大約需要15分鐘。如果漫游者執(zhí)行腳本失敗，出現(xiàn)一個(gè)錯(cuò)誤(比如一個(gè)錯(cuò)字)，你就有兩個(gè)問(wèn)題:

首先，反饋只在30分鐘后出現(xiàn)(探測(cè)器獲得腳本所需時(shí)間和接收錯(cuò)誤所需時(shí)間)

其次，腳本的某些部分已經(jīng)執(zhí)行，您可能必須對(duì)固定腳本進(jìn)行重大更改(這意味著您需要知道漫游車的當(dāng)前狀態(tài)……)

這里的原則是盡早失敗，也就是說(shuō)盡快編譯腳本失敗，如果可能的話向用戶提供反饋(包括漂亮的錯(cuò)誤消息)。

簡(jiǎn)而言之，類型檢查擴(kuò)展背后的思想是讓編譯器知道DSL使用的所有運(yùn)行時(shí)元編程技巧，這樣腳本就可以獲得與冗長(zhǎng)的靜態(tài)編譯代碼相同級(jí)別的編譯時(shí)檢查。我們將看到，您可以執(zhí)行普通類型檢查器無(wú)法執(zhí)行的檢查，從而為用戶提供強(qiáng)大的編譯時(shí)檢查。

2.2 extensions屬性

@TypeChecked注釋支持名為extensions的屬性。此參數(shù)接受一個(gè)字符串?dāng)?shù)組，對(duì)應(yīng)于類型檢查擴(kuò)展腳本列表。這些腳本在編譯時(shí)在類路徑中找到。例如:

@TypeChecked(extensions='/path/to/myextension.groovy')
void foo() { ...}

在這種情況下，foo方法將使用普通類型檢查器的規(guī)則進(jìn)行類型檢查，這些規(guī)則由myextension中找到的規(guī)則完成groovy腳本。

PS:注意，雖然在內(nèi)部類型檢查器支持多種機(jī)制來(lái)實(shí)現(xiàn)類型檢查擴(kuò)展(包括普通的舊java代碼)，但推薦的方法是使用那些類型檢查擴(kuò)展腳本。

2.3 用于類型檢查的DSL

類型檢查擴(kuò)展背后的思想是使用DSL來(lái)擴(kuò)展類型檢查器功能。這個(gè)DSL允許我們使用“event-driven”API鉤入編譯過(guò)程，更具體地說(shuō)是類型檢查階段。例如，當(dāng)類型檢查器進(jìn)入一個(gè)方法體時(shí)，它會(huì)拋出一個(gè)beforeVisitMethod事件，擴(kuò)展可以對(duì)該事件做出反應(yīng):

beforeVisitMethod { methodNode ->
println "Entering ${methodNode.name}"
}

假設(shè)我們手頭有這個(gè)漫游者DSL。用戶可以這樣寫:

robot.move 100

如果你有一個(gè)這樣定義的類:

class Robot {
Robot move(int qt) { this }
}

腳本可以在執(zhí)行之前使用以下腳本進(jìn)行類型檢查:

def config = new CompilerConfiguration()
config.addCompilationCustomizers(
   new ASTTransformationCustomizer(TypeChecked)//編譯器配置將@TypeChecked注釋添加到所有類中
)
def shell = new GroovyShell(config)//使用GroovyShell中的配置                        
def robot = new Robot()
shell.setVariable('robot', robot)
shell.evaluate(script)  //這樣，使用shell編譯的腳本將使用@ typecheck編譯，而用戶無(wú)需顯式地添加它

使用上面的編譯器配置，我們可以透明地將@typecheck應(yīng)用于腳本。在這種情況下，它將在編譯時(shí)失敗,輸出下面的錯(cuò)誤日志:

[Static type checking] - The variable [robot] is undeclared.

現(xiàn)在，我們將稍微更新配置以包含extensions參數(shù):

config.addCompilationCustomizers(
   new ASTTransformationCustomizer(
TypeChecked,
extensions:['robotextension.groovy'])
)

然后將以下內(nèi)容添加到類路徑中:

首先：創(chuàng)建一個(gè)robotextension.groovy文件，然后在文件中添加下面的代碼：

unresolvedVariable { var ->
    if ('robot'==var.name) {
        storeType(var, classNodeFor(Robot))
        handled = true
    }
}

在這里，我們告訴編譯器，如果找到一個(gè)未解析的變量，并且變量的名稱為robot，那么我們可以確保該變量的類型為robot。

2.4 類型檢查擴(kuò)展的相關(guān)API

AST：類型檢查API是一個(gè)低級(jí)API，處理抽象語(yǔ)法樹(shù)。要開(kāi)發(fā)擴(kuò)展，您必須很好地了解AST，即使DSL比處理純Java或Groovy的AST代碼要容易得多。

Events：類型檢查器發(fā)送以下事件，擴(kuò)展腳本可以對(duì)這些事件做出反應(yīng)。

具體的Events示例如下表所示：

事件名稱（Event name）	調(diào)用時(shí)間（Called When）	參數(shù)（Arguments）	使用（Usage）	備注
?`?setup?`?	在類型檢查器完成初始化后調(diào)用	沒(méi)有（none）	?`?setup { //它在任何其他操作之前被調(diào)用 }?`?	可以用來(lái)執(zhí)行設(shè)置我們的擴(kuò)展
?`?finish?`?	在類型檢查器完成類型檢查后調(diào)用	沒(méi)有（none）	?`?finish { // 這是在完成所有類型檢查之后 }?`?	可用于在類型檢查器完成其工作后執(zhí)行附加檢查。
?`?unresolvedVariable?`?	當(dāng)類型檢查器發(fā)現(xiàn)未解析的變量時(shí)調(diào)用	?`?VariableExpression vexp?`?	?`?unresolvedVariable { VariableExpression vexp -> if (vexp.name == 'people') { storeType(vexp, LIST_TYPE) handled = true } }?`?	允許開(kāi)發(fā)人員幫助類型檢查器使用用戶注入的變量。
?`?unresolvedProperty?`?	當(dāng)類型檢查器無(wú)法在接收器上找到屬性時(shí)調(diào)用	?`?PropertyExpression pexp?`?	?`?unresolvedProperty { PropertyExpression pexp -> if (pexp.propertyAsString == 'longueur' && getType(pexp.objectExpression) == STRING_TYPE) { storeType(pexp, int_TYPE) handled = true } }?`?	允許開(kāi)發(fā)人員處理“dynamic”屬性
?`?unresolvedAttribute?`?	當(dāng)類型檢查器無(wú)法在接收器上找到屬性時(shí)調(diào)用	?`?AttributeExpression aexp?`?	?`?unresolvedAttribute { AttributeExpression aexp -> if (getType(aexp.objectExpression) == STRING_TYPE) { storeType(aexp, STRING_TYPE) handled = true } }?`?	允許開(kāi)發(fā)人員處理缺失的屬性
?`?beforeMethodCall?`?	在類型檢查器開(kāi)始對(duì)方法調(diào)用進(jìn)行類型檢查之前調(diào)用	?`?MethodCall call?`?	?`?beforeMethodCall { call -> if (isMethodCallExpression(call) && call.methodAsString=='toUpperCase') { addStaticTypeError('Not allowed',call) handled = true } }?`?	允許您在類型檢查器執(zhí)行自己的檢查之前攔截方法調(diào)用。如果您想在有限的范圍內(nèi)用自定義類型檢查替換默認(rèn)類型檢查，這是很有用的。在這種情況下，必須將已處理標(biāo)志設(shè)置為true，以便類型檢查器跳過(guò)自己的檢查。
?`?afterMethodCall?`?	在類型檢查器完成方法調(diào)用的類型檢查后調(diào)用	?`?MethodCall call?`?	?`?afterMethodCall { call -> if (getTargetMethod(call).name=='toUpperCase') { addStaticTypeError('Not allowed',call) handled = true } }?`?	允許您在類型檢查器完成自己的檢查之后執(zhí)行額外的檢查。如果您希望執(zhí)行標(biāo)準(zhǔn)類型檢查測(cè)試，但也希望確保額外的類型安全性，例如檢查參數(shù)之間的差異，那么這一點(diǎn)特別有用。注意，?`?afterMethodCall?`??被調(diào)用，即使你在?`?beforemethodcall?`??之前做了，并將?`?handled?`?標(biāo)志設(shè)置為true。
?`?onMethodSelection?`?	當(dāng)類型檢查器找到適合方法調(diào)用的方法時(shí)，由它調(diào)用	?`?Expression expr, MethodNode node?`?	?`?onMethodSelection { expr, node -> if (node.declaringClass.name == 'java.lang.String') { if (++count>2) { addStaticTypeError("You can use only 2 calls on String in your source code",expr) } } }?`?	類型檢查器通過(guò)推斷方法調(diào)用的參數(shù)類型，然后選擇目標(biāo)方法來(lái)工作。如果它找到一個(gè)對(duì)應(yīng)的，那么它就觸發(fā)這個(gè)事件。例如，如果您想對(duì)特定的方法調(diào)用做出反應(yīng)，例如輸入一個(gè)以閉包作為參數(shù)的方法的作用域(如在構(gòu)建器中)，這是很有趣的。請(qǐng)注意，此事件可能針對(duì)各種類型的表達(dá)式拋出，而不僅僅是方法調(diào)用(例如二進(jìn)制表達(dá)式)。
?`?methodNotFound?`?	當(dāng)類型檢查器未能為方法調(diào)用找到合適的方法時(shí)，由它調(diào)用	?`?ClassNode receiver, String name, ArgumentListExpression argList, ClassNode[] argTypes,MethodCall call?`?	?`?methodNotFound { receiver, name, argList, argTypes, call -> if (receiver==classNodeFor(String) && name=='longueur' && argList.size()==0) { handled = true return newMethod('longueur', classNodeFor(String)) } }?`?	與?`?onMethodSelection?`??不同，當(dāng)類型檢查器無(wú)法為方法調(diào)用(instance或者 static)找到目標(biāo)方法時(shí)，此事件被發(fā)送。它使您有機(jī)會(huì)在錯(cuò)誤發(fā)送給用戶之前攔截錯(cuò)誤，但也可以設(shè)置目標(biāo)方法。為此，您需要返回?`?MethodNode?`??的列表。在大多數(shù)情況下，你會(huì)返回:一個(gè)空列表，這意味著你沒(méi)有找到相應(yīng)的方法，一個(gè)只有一個(gè)元素的列表，表明目標(biāo)方法是毫無(wú)疑問(wèn)的，如果你返回多個(gè)?`?MethodNode?`?，那么編譯器會(huì)向用戶拋出一個(gè)錯(cuò)誤，說(shuō)明方法調(diào)用是模糊的，列出可能的方法。為了方便起見(jiàn)，如果您只想返回一個(gè)方法，您可以直接返回它，而不是將它包裝到一個(gè)列表中。
?`?beforeVisitMethod?`?	在類型檢查方法體之前由類型檢查器調(diào)用	?`?MethodNode node?`?	?`?beforeVisitMethod { methodNode -> handled = methodNode.name.startsWith('skip') }?`?	類型檢查器將在開(kāi)始類型檢查方法體之前調(diào)用此方法。例如，如果您希望自己執(zhí)行類型檢查，而不是讓類型檢查器執(zhí)行，則必須將已處理標(biāo)志設(shè)置為true。此事件還可以用于幫助定義擴(kuò)展的作用域(例如，僅在方法foo中應(yīng)用它)。
?`?afterVisitMethod?`?	由類型檢查器在類型檢查方法體后調(diào)用	?`?MethodNode node?`?	?`?afterVisitMethod { methodNode -> scopeExit { if (methods>2) { addStaticTypeError("Method ${methodNode.name} contains more than 2 method calls", methodNode) } } }?`?	使您有機(jī)會(huì)在類型檢查器訪問(wèn)方法體后執(zhí)行額外的檢查。例如，如果您收集信息，并希望在收集完所有信息后執(zhí)行額外的檢查，這是非常有用的。
?`?beforeVisitClass?`?	在類型檢查類之前由類型檢查器調(diào)用	?`?ClassNode node?`?	?`?beforeVisitClass { ClassNode classNode -> def name = classNode.nameWithoutPackage if (!(name[0] in 'A'..'Z')) { addStaticTypeError("Class '${name}' doesn't start with an uppercase letter",classNode) } }?`?	如果一個(gè)類進(jìn)行了類型檢查，那么在訪問(wèn)該類之前，將發(fā)送此事件。對(duì)于在帶有?`?@typecheck?`?注釋的類中定義的內(nèi)部類也是如此。它可以幫助您定義擴(kuò)展的范圍，或者您甚至可以用自定義類型檢查實(shí)現(xiàn)完全取代類型檢查器的訪問(wèn)。為此，您必須將已處理標(biāo)志設(shè)置為true。
?`?afterVisitClass?`?	由類型檢查器在完成對(duì)類型檢查類的訪問(wèn)后調(diào)用	?`?ClassNode node?`?	?`?afterVisitClass { ClassNode classNode -> def name = classNode.nameWithoutPackage if (!(name[0] in 'A'..'Z')) { addStaticTypeError("Class '${name}' doesn't start with an uppercase letter",classNode) } }?`?	在類型檢查器完成它的工作后調(diào)用每個(gè)被類型檢查的類。這包括用?`?@typecheck?`?標(biāo)注的類，并且不會(huì)跳過(guò)在同一個(gè)類中定義的任何內(nèi)部/匿名類。
?`?incompatibleAssignment?`?	當(dāng)類型檢查器認(rèn)為賦值是不正確的，即賦值的右側(cè)與左側(cè)不兼容時(shí)調(diào)用	?`?ClassNode lhsType, ClassNode rhsType, Expression assignment?`?	?`?incompatibleAssignment { lhsType, rhsType, expr -> if (isBinaryExpression(expr) && isAssignment(expr.operation.type)) { if (lhsType==classNodeFor(int) && rhsType==classNodeFor(Closure)) { handled = true } } }?`?	使開(kāi)發(fā)人員能夠處理不正確的分配。例如，如果類覆蓋?`?setProperty?`??，這就很有用，因?yàn)樵谶@種情況下，將一種類型的變量分配給另一種類型的屬性可能是通過(guò)運(yùn)行時(shí)機(jī)制處理的。在這種情況下，您可以通過(guò)告訴類型檢查器賦值有效(使用?`?handled?`?? set to ?`?true?`?)來(lái)幫助類型檢查器。
?`?incompatibleReturnType?`?	當(dāng)類型檢查器認(rèn)為返回值與封閉閉包或方法的返回類型不兼容時(shí)調(diào)用	?`?ReturnStatement statement, ClassNode valueType?`?	?`?incompatibleReturnType { stmt, type -> if (type == STRING_TYPE) { handled = true } }?`?	使開(kāi)發(fā)人員能夠處理不正確的返回值。例如，當(dāng)返回值將進(jìn)行隱式轉(zhuǎn)換或封閉閉包的目標(biāo)類型難以正確推斷時(shí)，這很有用。在這種情況下，您可以通過(guò)告訴類型檢查器賦值有效(通過(guò)設(shè)置?`?Handler?`?的屬性)來(lái)幫助類型檢查器。
?`?ambiguousMethods?`?	當(dāng)類型檢查器無(wú)法在多個(gè)候選方法中進(jìn)行選擇時(shí)調(diào)用	?`?List<MethodNode> methods, Expression origin?`?	?`?ambiguousMethods { methods, origin -> methods.find { it.parameters.any { it.type == classNodeFor(Integer) } } }?`?	使開(kāi)發(fā)人員能夠處理不正確的分配。例如，如果類覆蓋?`?setProperty?`??，這就很有用，因?yàn)樵谶@種情況下，將一種類型的變量分配給另一種類型的屬性可能是通過(guò)運(yùn)行時(shí)機(jī)制處理的。在這種情況下，您可以通過(guò)告訴類型檢查器賦值有效(使用?`?handled?`?? set to ?`?true?`?)來(lái)幫助類型檢查器。

(PS: 上面的表格看不清楚的，可以訪問(wèn)我的博客網(wǎng)站：zinyan.com/?p=486)當(dāng)然，擴(kuò)展腳本可能由幾個(gè)塊組成，可以使用多個(gè)塊響應(yīng)同一個(gè)事件。這使得DSL看起來(lái)更好，更容易編寫。然而，僅僅對(duì)事件做出反應(yīng)是遠(yuǎn)遠(yuǎn)不夠的。如果我們知道可以對(duì)事件做出反應(yīng)，那么還需要處理錯(cuò)誤，這意味著有幾個(gè)幫助器方法可以使事情變得更簡(jiǎn)單。

責(zé)任編輯：武曉燕來(lái)源： zinyan

Groovy DSL?Groovy