Groovy 类型检查扩展，使用扩展

在上一篇介绍了基本的Groovy的类型检查扩展，以及该扩展的意义和部分的API说明。,本篇接着上篇没有讲完的内容，继续介绍类型检查扩展的相关知识点。,我们讲解了如何创建类型检查扩展，这里开始讲解各种的使用方式。,DSL依赖于一个名为org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport的支持类。这个类本身扩展了org.codehaus.groovy.transform.stc.TypeCheckingExtension。这两个类定义了许多帮助器方法，使使用AST变得更容易，特别是在类型检查方面。要知道的一件有趣的事情是，我们可以访问类型检查器。这意味着我们可以以编程方式调用类型检查器的方法，包括那些允许抛出编译错误的方法。,扩展脚本委托给org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport类，这意味着我们可以直接访问以下变量:,类型检查上下文包含大量在上下文中对类型检查器有用的信息。例如，当前的封闭方法调用堆栈、二进制表达式、闭包等等，如果我们必须知道错误发生时我们在哪里以及我们想要处理它，那么这些信息就特别重要。,除了GroovyTypeCheckingExtensionSupport和StaticTypeCheckingVisitor提供的功能外，类型检查DSL脚本还从org.codehaus.groovy.ast.ClassHelper和org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport导入静态成员，允许通过OBJECT_TYPE、STRING_TYPE、THROWABLE_TYPE等对公共类型进行访问，并检查诸如missesgenericsttypes(ClassNode)、isClassClassNodeWrappingConcreteType(ClassNode)等。,在使用类型检查扩展时，需要特别注意处理类节点。编译使用抽象语法树(AST)，当您检查类的类型时，该树可能不完整。这也意味着在引用类型时，不能使用String或HashSet等类字面量，而是使用表示这些类型的类节点。这需要一定程度的抽象和理解Groovy如何处理类节点。为了简化工作，Groovy提供了几个辅助方法来处理类节点。例如，如果你想说“String的类型”，你可以这样写:,还会注意到，classNodeFor有一个变体，它以String而不是Class作为参数。一般来说，我们不应该使用该方法，因为它将创建一个名称为String的类节点，但没有在其上定义任何方法、任何属性等。第一个版本返回已解析的类节点，而第二个版本返回未解析的类节点。所以后者应该留给非常特殊的情况。,可能遇到的第二个问题是引用一个尚未编译的类型。这种情况发生的频率可能比你想象的要高。例如，当一起编译一组文件时。在这种情况下，如果你想说“那个变量是Foo类型的”，但Foo还没有编译，仍然可以使用lookupClassNodeFor引用Foo类节点:,假设你知道变量foo的类型是Foo，你想告诉类型检查器。然后可以使用storeType方法，该方法接受两个参数:第一个参数是希望存储类型的节点，第二个参数是节点的类型。如果查看storeType的实现，我们将看到它委托给类型检查器等效方法，该方法本身做了大量工作来存储节点元数据。还将看到，存储类型并不局限于变量:可以设置任何表达式的类型。,同样，获取AST节点的类型只需调用该节点上的getType即可。这通常是你想要的，但有一些注意事项:,要抛出一个类型检查错误，你只需要调用addStaticTypeError方法，它有两个参数:,通常需要知道AST节点的类型。为了可读性DSL提供了一个特殊的isXXXExpression方法，该方法将委托给XXXExpression的x实例。例如:,不建议的写法:,正确，推荐的写法:,当我们执行动态代码的类型检查时，可能经常会遇到这样的情况:知道一个方法调用是有效的，但它背后并没有“真正的”方法。,以Grails动态查找器为例。可以有一个由名为findByName(…)的方法组成的方法调用。,由于bean中没有定义findByName方法，类型检查器会报错。,但是，我们知道这个方法在运行时不会失败，甚至可以知道这个方法的返回类型是什么。,对于这种情况，DSL支持由虚拟方法组成的两个特殊构造。这意味着将返回一个实际上并不存在但在类型检查上下文中定义的方法节点。有三种方法:,所有这三个方法都做同样的事情:它们创建一个新的方法节点，其名称是提供的名称，并定义该方法的返回类型。,此外，类型检查器会将这些方法添加到generatedMethods列表中。我们只设置名称和返回类型的原因是，这是在90%的情况下所需要的。,例如，在上面的findByName示例中，只需要知道findByName不会在运行时失败，并且它返回一个域类。,返回类型的Callable版本很有趣，因为当类型检查器实际需要返回类型时，它推迟了返回类型的计算。,在某些情况下，当类型检查器要求返回类型时，可能不知道实际的返回类型，因此可以使用闭包，每当类型检查器在此方法节点上调用getReturnType时，都会调用闭包。,如果将此与延迟检查结合起来，就可以实现相当复杂的类型检查，包括前向引用的处理。,如果你需要的不仅仅是名称和返回类型，你可以自己创建一个新的MethodNode。,范围在DSL类型检查中非常重要，这也是为什么我们不能使用基于切入点的方法来进行DSL类型检查的原因之一。,基本上，必须能够非常精确地定义何时应用扩展，何时不应用扩展。此外，必须能够处理常规类型检查器无法处理的情况，例如前向引用:,例如，你想处理一个构建器:,因此，我们的扩展应该只在输入foo方法时是活动的，并且在此范围之外是不活动的。,但是，可能会遇到复杂的情况，比如同一个文件中有多个构建程序或嵌入式构建程序(构建程序中的构建程序)。,虽然不应该尝试从一开始就修复所有这些问题(必须接受类型检查的限制)，但类型检查器确实提供了一种很好的机制来处理这个问题:使用newScope和scopeExit方法的作用域堆栈。,范围包括:,如果想看一下实现，它只是一个LinkedHashMap (org.codehaus.groovytypecheckingextensionsupport.typecheckingscope)，但是它非常强大。例如，可以使用这样的作用域来存储退出作用域时要执行的闭包列表。这是处理前向引用的方式:,也就是说，如果在某个时候无法确定表达式的类型，或者此时无法检查赋值是否有效，仍然可以稍后进行检查……这是一个非常强大的功能。,现在，newScope和scopeExit提供了一些有趣的语法糖:,在DSL中的任何时候，都可以使用getCurrentScope()或更简单的currentScope访问当前作用域:,一般的模式是:,要获得helper方法的完整列表，请参考类org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport和类org.codehaus.groovy.transform.stc.TypeCheckingExtension。但是，要特别注意以下方法:,关于类型检测扩展的使用相关知识要点，就介绍到这里了。以上相关内容可以参考Groovy官方文档：http://docs.groovy-lang.org/docs/groovy-4.0.6/html/documentation/#Typecheckingextensions-Workingwithextensions进行查询。,