建站
咨詢
售后
建站咨詢
新聞中心
1. 介紹
本篇Groovy學習筆記第37篇。開始介紹Groovy中的擴展類型檢查相關知識。學會如何定義我們的類型檢查器。
成都創(chuàng)新互聯(lián)公司專業(yè)提供成都主機托管四川主機托管成都服務器托管四川服務器托管，支持按月付款！我們的承諾：貴族品質(zhì)、平民價格，機房位于中國電信/網(wǎng)通/移動機房，成都服務器托管服務有保障！
在前面分享的關于類型知識，更多的是依靠Groovy中的靜態(tài)類型檢查器實現(xiàn)的。
而本篇開始要介紹的就是定義我們自己的類型檢查。也就叫做類型檢查擴展，定義自己的類型檢查器。
類型檢查擴展是一種機制，它允許DSL引擎的開發(fā)人員對常規(guī)groovy類應用靜態(tài)類型檢查所允許的相同類型的檢查，從而使這些腳本更加安全。
PS：總的來說，類型檢測擴展的相關知識，可能更多的適合于采用Groovy進行插件開發(fā)的工程師使用。用于檢測定義的DSL腳本是否合規(guī)等。
2. 編寫類型檢查擴展
下面來介紹，如何編寫我們的類型檢查。
2.1 智能的類型檢查器
Groovy可以在編譯時與靜態(tài)類型檢查器一起使用，使用@TypeChecked注解啟用。在這種模式下，編譯器會變得更加冗長，并拋出錯誤，例如拼寫錯誤、不存在的方法等。不過，這也帶來了一些限制，其中大多數(shù)限制來自Groovy本質(zhì)上仍然是一種動態(tài)語言。例如，你不能在使用標記構建器的代碼上使用類型檢查:
def builder = new MarkupBuilder(out)
builder.html {
head {
// ...
}
body {
p 'Hello, world!'
}
}
在上面的例子中，html、head、body或p方法都不存在。但是，如果執(zhí)行代碼，它可以工作，因為Groovy使用動態(tài)分派并在運行時轉換這些方法調(diào)用。在這個構建器中，我們可以使用的標記數(shù)量和屬性都沒有限制，這意味著類型檢查器沒有機會在編譯時知道所有可能的方法(標記)，除非我們創(chuàng)建一個專用于HTML的構建器。
Groovy是實現(xiàn)內(nèi)部DSL的選擇平臺。靈活的語法，結合運行時和編譯時元編程功能，使Groovy成為一個有趣的選擇，因為它允許程序員專注于DSL，而不是工具或?qū)崿F(xiàn)。由于Groovy DSL是Groovy代碼，因此很容易獲得IDE工具的支持，而不必編寫專門的插件。
在很多情況下，DSL引擎是用Groovy(或Java)編寫的，然后用戶代碼作為腳本執(zhí)行，這意味著在用戶邏輯之上有某種包裝器。例如，包裝器可能包含在GroovyShell或GroovyScriptEngine中，它們在運行腳本之前透明地執(zhí)行一些任務(添加導入、應用AST轉換、擴展基本腳本等等)。通常，用戶編寫的腳本無需測試就可以投入生產(chǎn)，因為DSL邏輯達到了任何用戶都可以使用DSL語法編寫代碼的地步。最后，用戶可能會忽略他們所編寫的實際上是代碼。這為DSL實現(xiàn)者增加了一些挑戰(zhàn)，例如確保用戶代碼的執(zhí)行，或者在這種情況下，及早報告錯誤。
例如，想象一個DSL：其目標是遠程駕駛火星上的漫游者。向探測器發(fā)送信息大約需要15分鐘。如果漫游者執(zhí)行腳本失敗，出現(xiàn)一個錯誤(比如一個錯字)，你就有兩個問題:
首先，反饋只在30分鐘后出現(xiàn)(探測器獲得腳本所需時間和接收錯誤所需時間)
其次，腳本的某些部分已經(jīng)執(zhí)行，您可能必須對固定腳本進行重大更改(這意味著您需要知道漫游車的當前狀態(tài)……)
類型檢查擴展是一種機制，它允許DSL引擎的開發(fā)人員對常規(guī)groovy類應用靜態(tài)類型檢查所允許的相同類型的檢查，從而使這些腳本更加安全。
這里的原則是盡早失敗，也就是說盡快編譯腳本失敗，如果可能的話向用戶提供反饋(包括漂亮的錯誤消息)。
簡而言之，類型檢查擴展背后的思想是讓編譯器知道DSL使用的所有運行時元編程技巧，這樣腳本就可以獲得與冗長的靜態(tài)編譯代碼相同級別的編譯時檢查。我們將看到，您可以執(zhí)行普通類型檢查器無法執(zhí)行的檢查，從而為用戶提供強大的編譯時檢查。
2.2 extensions屬性
@TypeChecked注釋支持名為extensions的屬性。此參數(shù)接受一個字符串數(shù)組，對應于類型檢查擴展腳本列表。這些腳本在編譯時在類路徑中找到。例如:
@TypeChecked(extensions='/path/to/myextension.groovy')
void foo() { ...}
在這種情況下，foo方法將使用普通類型檢查器的規(guī)則進行類型檢查，這些規(guī)則由myextension中找到的規(guī)則完成groovy腳本。
PS:注意，雖然在內(nèi)部類型檢查器支持多種機制來實現(xiàn)類型檢查擴展(包括普通的舊java代碼)，但推薦的方法是使用那些類型檢查擴展腳本。
2.3 用于類型檢查的DSL
類型檢查擴展背后的思想是使用DSL來擴展類型檢查器功能。這個DSL允許我們使用“event-driven”API鉤入編譯過程，更具體地說是類型檢查階段。例如，當類型檢查器進入一個方法體時，它會拋出一個beforeVisitMethod事件，擴展可以對該事件做出反應:
beforeVisitMethod { methodNode ->
println "Entering ${methodNode.name}"
}假設我們手頭有這個漫游者DSL。用戶可以這樣寫:
robot.move 100
如果你有一個這樣定義的類:
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.
現(xiàn)在，我們將稍微更新配置以包含extensions參數(shù):
config.addCompilationCustomizers(
new ASTTransformationCustomizer(
TypeChecked,
extensions:['robotextension.groovy'])
)
然后將以下內(nèi)容添加到類路徑中:
首先：創(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） |
調(diào)用時間（Called When） |
參數(shù)（Arguments） |
使用（Usage） |
備注 |
|
? |
在類型檢查器完成初始化后調(diào)用 |
沒有（none） |
? |
可以用來執(zhí)行設置我們的擴展 |
|
? |
在類型檢查器完成類型檢查后調(diào)用 |
沒有（none） |
? |
可用于在類型檢查器完成其工作后執(zhí)行附加檢查。 |
|
? |
當類型檢查器發(fā)現(xiàn)未解析的變量時調(diào)用 |
? |
? |
允許開發(fā)人員幫助類型檢查器使用用戶注入的變量。 |
|
? |
當類型檢查器無法在接收器上找到屬性時調(diào)用 |
? |
? |
允許開發(fā)人員處理“dynamic”屬性 |
|
? |
當類型檢查器無法在接收器上找到屬性時調(diào)用 |
? |
? |
允許開發(fā)人員處理缺失的屬性 |
|
? |
在類型檢查器開始對方法調(diào)用進行類型檢查之前調(diào)用 |
? |
? |
允許您在類型檢查器執(zhí)行自己的檢查之前攔截方法調(diào)用。如果您想在有限的范圍內(nèi)用自定義類型檢查替換默認類型檢查，這是很有用的。在這種情況下，必須將已處理標志設置為true，以便類型檢查器跳過自己的檢查。 |
|
? |
在類型檢查器完成方法調(diào)用的類型檢查后調(diào)用 |
? |
? |
允許您在類型檢查器完成自己的檢查之后執(zhí)行額外的檢查。如果您希望執(zhí)行標準類型檢查測試，但也希望確保額外的類型安全性，例如檢查參數(shù)之間的差異，那么這一點特別有用。注意，? |
|
? |
當類型檢查器找到適合方法調(diào)用的方法時，由它調(diào)用 |
? |
? |
類型檢查器通過推斷方法調(diào)用的參數(shù)類型，然后選擇目標方法來工作。如果它找到一個對應的，那么它就觸發(fā)這個事件。例如，如果您想對特定的方法調(diào)用做出反應，例如輸入一個以閉包作為參數(shù)的方法的作用域(如在構建器中)，這是很有趣的。請注意，此事件可能針對各種類型的表達式拋出，而不僅僅是方法調(diào)用(例如二進制表達式)。 |
|
? |
當類型檢查器未能為方法調(diào)用找到合適的方法時，由它調(diào)用 |
? |
? |
與? |
|
? |
在類型檢查方法體之前由類型檢查器調(diào)用 |
? |
? |
類型檢查器將在開始類型檢查方法體之前調(diào)用此方法。例如，如果您希望自己執(zhí)行類型檢查，而不是讓類型檢查器執(zhí)行，則必須將已處理標志設置為true。此事件還可以用于幫助定義擴展的作用域(例如，僅在方法foo中應用它)。 |
|
? |
由類型檢查器在類型檢查方法體后調(diào)用 |
? |
? |
使您有機會在類型檢查器訪問方法體后執(zhí)行額外的檢查。例如，如果您收集信息，并希望在收集完所有信息后執(zhí)行額外的檢查，這是非常有用的。 |
|
? |
在類型檢查類之前由類型檢查器調(diào)用 |
? |
? |
如果一個類進行了類型檢查，那么在訪問該類之前，將發(fā)送此事件。對于在帶有? |
|
? |
由類型檢查器在完成對類型檢查類的訪問后調(diào)用 |
? |
? |
在類型檢查器完成它的工作后調(diào)用每個被類型檢查的類。這包括用? |
|
? |
當類型檢查器認為賦值是不正確的，即賦值的右側與左側不兼容時調(diào)用 |
? |
? |
使開發(fā)人員能夠處理不正確的分配。例如，如果類覆蓋? |
|
? |
當類型檢查器認為返回值與封閉閉包或方法的返回類型不兼容時調(diào)用 |
? |
? |
使開發(fā)人員能夠處理不正確的返回值。例如，當返回值將進行隱式轉換或封閉閉包的目標類型難以正確推斷時，這很有用。在這種情況下，您可以通過告訴類型檢查器賦值有效(通過設置? |
|
? |
當類型檢查器無法在多個候選方法中進行選擇時調(diào)用 |
? |
? |
使開發(fā)人員能夠處理不正確的分配。例如，如果類覆蓋? |
(PS: 上面的表格看不清楚的，可以訪問我的博客網(wǎng)站：zinyan.com/?p=486)當然，擴展腳本可能由幾個塊組成，可以使用多個塊響應同一個事件。這使得DSL看起來更好，更容易編寫。然而，僅僅對事件做出反應是遠遠不夠的。如果我們知道可以對事件做出反應，那么還需要處理錯誤，這意味著有幾個幫助器方法可以使事情變得更簡單。
標題名稱：Groovy類型檢查擴展，編寫類型檢查擴展
網(wǎng)頁地址：http://m.fisionsoft.com.cn/article/djieesc.html
