1. 介紹
本篇Groovy學習筆記第37篇。開始介紹Groovy中的擴展類型檢查相關知識。學會如何定義我們的類型檢查器。
在前面分享的關于類型知識，更多的是依靠Groovy中的靜態(tài)類型檢查器實現的。
而本篇開始要介紹的就是定義我們自己的類型檢查。也就叫做類型檢查擴展，定義自己的類型檢查器。
類型檢查擴展是一種機制，它允許DSL引擎的開發(fā)人員對常規(guī)groovy類應用靜態(tài)類型檢查所允許的相同類型的檢查，從而使這些腳本更加安全。
PS：總的來說，類型檢測擴展的相關知識，可能更多的適合于采用Groovy進行插件開發(fā)的工程師使用。用于檢測定義的DSL腳本是否合規(guī)等。
2. 編寫類型檢查擴展
下面來介紹，如何編寫我們的類型檢查。
2.1 智能的類型檢查器
Groovy可以在編譯時與靜態(tài)類型檢查器一起使用，使用@TypeChecked注解啟用。在這種模式下，編譯器會變得更加冗長，并拋出錯誤，例如拼寫錯誤、不存在的方法等。不過，這也帶來了一些限制，其中大多數限制來自Groovy本質上仍然是一種動態(tài)語言。例如，你不能在使用標記構建器的代碼上使用類型檢查:
def builder = new MarkupBuilder(out)
builder.html {
head {
// ...
}
body {
p 'Hello, world!'
}
}
在上面的例子中，html、head、body或p方法都不存在。但是，如果執(zhí)行代碼，它可以工作，因為Groovy使用動態(tài)分派并在運行時轉換這些方法調用。在這個構建器中，我們可以使用的標記數量和屬性都沒有限制，這意味著類型檢查器沒有機會在編譯時知道所有可能的方法(標記)，除非我們創(chuàng)建一個專用于HTML的構建器。
Groovy是實現內部DSL的首選平臺。靈活的語法，結合運行時和編譯時元編程功能，使Groovy成為一個有趣的選擇，因為它允許程序員專注于DSL，而不是工具或實現。由于Groovy DSL是Groovy代碼，因此很容易獲得IDE工具的支持，而不必編寫專門的插件。
在很多情況下，DSL引擎是用Groovy(或Java)編寫的，然后用戶代碼作為腳本執(zhí)行，這意味著在用戶邏輯之上有某種包裝器。例如，包裝器可能包含在GroovyShell或GroovyScriptEngine中，它們在運行腳本之前透明地執(zhí)行一些任務(添加導入、應用AST轉換、擴展基本腳本等等)。通常，用戶編寫的腳本無需測試就可以投入生產，因為DSL邏輯達到了任何用戶都可以使用DSL語法編寫代碼的地步。最后，用戶可能會忽略他們所編寫的實際上是代碼。這為DSL實現者增加了一些挑戰(zhàn)，例如確保用戶代碼的執(zhí)行，或者在這種情況下，及早報告錯誤。
例如，想象一個DSL：其目標是遠程駕駛火星上的漫游者。向探測器發(fā)送信息大約需要15分鐘。如果漫游者執(zhí)行腳本失敗，出現一個錯誤(比如一個錯字)，你就有兩個問題:
首先，反饋只在30分鐘后出現(探測器獲得腳本所需時間和接收錯誤所需時間)
其次，腳本的某些部分已經執(zhí)行，您可能必須對固定腳本進行重大更改(這意味著您需要知道漫游車的當前狀態(tài)……)
類型檢查擴展是一種機制，它允許DSL引擎的開發(fā)人員對常規(guī)groovy類應用靜態(tài)類型檢查所允許的相同類型的檢查，從而使這些腳本更加安全。
這里的原則是盡早失敗，也就是說盡快編譯腳本失敗，如果可能的話向用戶提供反饋(包括漂亮的錯誤消息)。
簡而言之，類型檢查擴展背后的思想是讓編譯器知道DSL使用的所有運行時元編程技巧，這樣腳本就可以獲得與冗長的靜態(tài)編譯代碼相同級別的編譯時檢查。我們將看到，您可以執(zhí)行普通類型檢查器無法執(zhí)行的檢查，從而為用戶提供強大的編譯時檢查。
2.2 extensions屬性
@TypeChecked注釋支持名為extensions的屬性。此參數接受一個字符串數組，對應于類型檢查擴展腳本列表。這些腳本在編譯時在類路徑中找到。例如:
@TypeChecked(extensions='/path/to/myextension.groovy')
void foo() { ...}
在這種情況下，foo方法將使用普通類型檢查器的規(guī)則進行類型檢查，這些規(guī)則由myextension中找到的規(guī)則完成groovy腳本。
PS:注意，雖然在內部類型檢查器支持多種機制來實現類型檢查擴展(包括普通的舊java代碼)，但推薦的方法是使用那些類型檢查擴展腳本。
2.3 用于類型檢查的DSL
類型檢查擴展背后的思想是使用DSL來擴展類型檢查器功能。這個DSL允許我們使用“event-driven”API鉤入編譯過程，更具體地說是類型檢查階段。例如，當類型檢查器進入一個方法體時，它會拋出一個beforeVisitMethod事件，擴展可以對該事件做出反應:
beforeVisitMethod { methodNode ->
println "Entering ${methodNode.name}"
}假設我們手頭有這個漫游者DSL。用戶可以這樣寫:
如果你有一個這樣定義的類:
class Robot {
Robot move(int qt) { this }
}腳本可以在執(zhí)行之前使用以下腳本進行類型檢查:
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編譯，而用戶無需顯式地添加它
使用上面的編譯器配置，我們可以透明地將@typecheck應用于腳本。在這種情況下，它將在編譯時失敗,輸出下面的錯誤日志:
[Static type checking] - The variable [robot] is undeclared.
現在，我們將稍微更新配置以包含extensions參數:
config.addCompilationCustomizers(
new ASTTransformationCustomizer(
TypeChecked,
extensions:['robotextension.groovy'])
)
然后將以下內容添加到類路徑中:
首先：創(chuàng)建一個robotextension.groovy文件，然后在文件中添加下面的代碼：
unresolvedVariable { var ->
if ('robot'==var.name) {
storeType(var, classNodeFor(Robot))
handled = true
}
}在這里，我們告訴編譯器，如果找到一個未解析的變量，并且變量的名稱為robot，那么我們可以確保該變量的類型為robot。
2.4 類型檢查擴展的相關API
AST：類型檢查API是一個低級API，處理抽象語法樹。要開發(fā)擴展，您必須很好地了解AST，即使DSL比處理純Java或Groovy的AST代碼要容易得多。
Events：類型檢查器發(fā)送以下事件，擴展腳本可以對這些事件做出反應。
具體的Events示例如下表所示：
事件名稱（Event name）
| 調用時間（Called When）
| 參數（Arguments）
| 使用（Usage）
| 備注
|
??setup?? | 在類型檢查器完成初始化后調用
| 沒有（none）
| ??setup { //它在任何其他操作之前被調用 }?? | 可以用來執(zhí)行設置我們的擴展
|
??finish?? | 在類型檢查器完成類型檢查后調用
| 沒有（none）
| ??finish { // 這是在完成所有類型檢查之后 }?? | 可用于在類型檢查器完成其工作后執(zhí)行附加檢查。
|
??unresolvedVariable?? | 當類型檢查器發(fā)現未解析的變量時調用
| ??VariableExpression vexp?? | ??unresolvedVariable { VariableExpression vexp -> if (vexp.name == 'people') { storeType(vexp, LIST_TYPE) handled = true } }?? | 允許開發(fā)人員幫助類型檢查器使用用戶注入的變量。
|
??unresolvedProperty?? | 當類型檢查器無法在接收器上找到屬性時調用
| ??PropertyExpression pexp?? | ??unresolvedProperty { PropertyExpression pexp -> if (pexp.propertyAsString == 'longueur' && getType(pexp.objectExpression) == STRING_TYPE) { storeType(pexp, int_TYPE) handled = true } }?? | 允許開發(fā)人員處理“dynamic”屬性
|
??unresolvedAttribute?? | 當類型檢查器無法在接收器上找到屬性時調用
| ??AttributeExpression aexp?? | ??unresolvedAttribute { AttributeExpression aexp -> if (getType(aexp.objectExpression) == STRING_TYPE) { storeType(aexp, STRING_TYPE) handled = true } }?? | 允許開發(fā)人員處理缺失的屬性
|
??beforeMethodCall?? | 在類型檢查器開始對方法調用進行類型檢查之前調用
| ??MethodCall call?? | ??beforeMethodCall { call -> if (isMethodCallExpression(call) && call.methodAsString=='toUpperCase') { addStaticTypeError('Not allowed',call) handled = true } }?? | 允許您在類型檢查器執(zhí)行自己的檢查之前攔截方法調用。如果您想在有限的范圍內用自定義類型檢查替換默認類型檢查，這是很有用的。在這種情況下，必須將已處理標志設置為true，以便類型檢查器跳過自己的檢查。
|
??afterMethodCall?? | 在類型檢查器完成方法調用的類型檢查后調用
| ??MethodCall call?? | ??afterMethodCall { call -> if (getTargetMethod(call).name=='toUpperCase') { addStaticTypeError('Not allowed',call) handled = true } }?? | 允許您在類型檢查器完成自己的檢查之后執(zhí)行額外的檢查。如果您希望執(zhí)行標準類型檢查測試，但也希望確保額外的類型安全性，例如檢查參數之間的差異，那么這一點特別有用。注意，??afterMethodCall???被調用，即使你在??beforemethodcall???之前做了，并將??handled??標志設置為true。 |
??onMethodSelection?? | 當類型檢查器找到適合方法調用的方法時，由它調用
| ??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) } } }?? | 類型檢查器通過推斷方法調用的參數類型，然后選擇目標方法來工作。如果它找到一個對應的，那么它就觸發(fā)這個事件。例如，如果您想對特定的方法調用做出反應，例如輸入一個以閉包作為參數的方法的作用域(如在構建器中)，這是很有趣的。請注意，此事件可能針對各種類型的表達式拋出，而不僅僅是方法調用(例如二進制表達式)。
|
??methodNotFound?? | 當類型檢查器未能為方法調用找到合適的方法時，由它調用
| ??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???不同，當類型檢查器無法為方法調用(instance或者 static)找到目標方法時，此事件被發(fā)送。它使您有機會在錯誤發(fā)送給用戶之前攔截錯誤，但也可以設置目標方法。為此，您需要返回??MethodNode???的列表。在大多數情況下，你會返回:一個空列表，這意味著你沒有找到相應的方法，一個只有一個元素的列表，表明目標方法是毫無疑問的，如果你返回多個??MethodNode??，那么編譯器會向用戶拋出一個錯誤，說明方法調用是模糊的，列出可能的方法。為了方便起見，如果您只想返回一個方法，您可以直接返回它，而不是將它包裝到一個列表中。 |
??beforeVisitMethod?? | 在類型檢查方法體之前由類型檢查器調用
| ??MethodNode node?? | ??beforeVisitMethod { methodNode -> handled = methodNode.name.startsWith('skip') }?? | 類型檢查器將在開始類型檢查方法體之前調用此方法。例如，如果您希望自己執(zhí)行類型檢查，而不是讓類型檢查器執(zhí)行，則必須將已處理標志設置為true。此事件還可以用于幫助定義擴展的作用域(例如，僅在方法foo中應用它)。
|
??afterVisitMethod?? | 由類型檢查器在類型檢查方法體后調用
| ??MethodNode node?? | ??afterVisitMethod { methodNode -> scopeExit { if (methods>2) { addStaticTypeError("Method ${methodNode.name} contains more than 2 method calls", methodNode) } } }?? | 使您有機會在類型檢查器訪問方法體后執(zhí)行額外的檢查。例如，如果您收集信息，并希望在收集完所有信息后執(zhí)行額外的檢查，這是非常有用的。
|
??beforeVisitClass?? | 在類型檢查類之前由類型檢查器調用
| ??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) } }?? | 如果一個類進行了類型檢查，那么在訪問該類之前，將發(fā)送此事件。對于在帶有??@typecheck??注釋的類中定義的內部類也是如此。它可以幫助您定義擴展的范圍，或者您甚至可以用自定義類型檢查實現完全取代類型檢查器的訪問。為此，您必須將已處理標志設置為true。 |
??afterVisitClass?? | 由類型檢查器在完成對類型檢查類的訪問后調用
| ??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) } }?? | 在類型檢查器完成它的工作后調用每個被類型檢查的類。這包括用??@typecheck??標注的類，并且不會跳過在同一個類中定義的任何內部/匿名類。 |
??incompatibleAssignment?? | 當類型檢查器認為賦值是不正確的，即賦值的右側與左側不兼容時調用
| ??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 } } }?? | 使開發(fā)人員能夠處理不正確的分配。例如，如果類覆蓋??setProperty???，這就很有用，因為在這種情況下，將一種類型的變量分配給另一種類型的屬性可能是通過運行時機制處理的。在這種情況下，您可以通過告訴類型檢查器賦值有效(使用??handled??? set to ??true??)來幫助類型檢查器。 |
??incompatibleReturnType?? | 當類型檢查器認為返回值與封閉閉包或方法的返回類型不兼容時調用
| ??ReturnStatement statement, ClassNode valueType?? | ??incompatibleReturnType { stmt, type -> if (type == STRING_TYPE) { handled = true } }?? | 使開發(fā)人員能夠處理不正確的返回值。例如，當返回值將進行隱式轉換或封閉閉包的目標類型難以正確推斷時，這很有用。在這種情況下，您可以通過告訴類型檢查器賦值有效(通過設置??Handler??的屬性)來幫助類型檢查器。 |
??ambiguousMethods?? | 當類型檢查器無法在多個候選方法中進行選擇時調用
| ??List<MethodNode> methods, Expression origin?? | ??ambiguousMethods { methods, origin -> methods.find { it.parameters.any { it.type == classNodeFor(Integer) } } }?? | 使開發(fā)人員能夠處理不正確的分配。例如，如果類覆蓋??setProperty???，這就很有用，因為在這種情況下，將一種類型的變量分配給另一種類型的屬性可能是通過運行時機制處理的。在這種情況下，您可以通過告訴類型檢查器賦值有效(使用??handled??? set to ??true??)來幫助類型檢查器。 |
(PS: 上面的表格看不清楚的，可以訪問我的博客網站：zinyan.com/?p=486)當然，擴展腳本可能由幾個塊組成，可以使用多個塊響應同一個事件。這使得DSL看起來更好，更容易編寫。然而，僅僅對事件做出反應是遠遠不夠的。如果我們知道可以對事件做出反應，那么還需要處理錯誤，這意味著有幾個幫助器方法可以使事情變得更簡單。
