Подразумевает ли groovy @CompileStatic @TypeChecked? - PullRequest
0 голосов
/ 17 апреля 2019

Я добавил @TypeChecked и @CompileStatic в код Groovy.

Компилятор принимает это, но это избыточно? TypeChecked добавляет что-нибудь, что CompileStatic не делает? Документы, кажется, подразумевают, что CompileStatic является надмножеством, но не будем говорить об этом прямо. Я хотел бы выполнить статическую компиляцию, время от времени отключая строгую проверку типов, чтобы позволить Groovy auto-typecast при перехвате ссылок с ошибками или отсутствующих методов.

Пример:

@TypeChecked
@CompileStatic
class MyClass {
    void simple() {
        // compiles fine statically
    }

    @TypeChecked(SKIP)
    void complicated() {
        // would require too many ugly typecasts
    }

    @CompileDynamic
    void evenworse() {
        // need time to untangle this
    }
}

Я прочитал Разница между @TypeChecked и @ CompileStatic , и он не ответил на этот конкретный вопрос. Предполагается, что TypeCast допускает некоторые дополнительные проверки, но я не знаю, выполняет ли он дополнительные проверки по умолчанию.

1 Ответ

1 голос
/ 18 апреля 2019

Я бы сказал, да, CompileStatic подразумевает TypeChecked.Рассматривая базовый источник для интерфейсов аннотаций TypeChecked и CompileStatic, мы видим:

// TypeChecked.java
@GroovyASTTransformationClass("org.codehaus.groovy.transform.StaticTypesTransformation")
public @interface TypeChecked {

и

// CompileStatic.java
@GroovyASTTransformationClass("org.codehaus.groovy.transform.sc.StaticCompileTransformation")
public @interface CompileStatic {
...

, что говорит нам о том, что классы выполняют фактические преобразования AST(работа аннотаций) StaticCompileTransformation и StaticTypesTransformation.

Глядя на код для тех, кого мы получаем:

// Transformation for TypeChecked
public class StaticTypesTransformation implements ASTTransformation, CompilationUnitAware {

и

// Transformation for CompileStatic
public class StaticCompileTransformation extends StaticTypesTransformation {

т.е. преобразование для CompileStatic расширяет преобразование для TypeChecked, таким образомКазалось бы, поведение CompileStatic действительно является надмножеством поведения TypeChecked.

<< edit >>

Копая еще глубже, мы видим, что классы преобразования используют шаблон посетителей и имеют соответственно следующие методы:

    // StaticTypesTransformation, transformation for TypeChecked
    protected StaticTypeCheckingVisitor newVisitor(SourceUnit unit, ClassNode node) {
        return new StaticTypeCheckingVisitor(unit, node);
    }

и

    // StaticCompileTransformation, transformation for CompileStatic 
    protected StaticTypeCheckingVisitor newVisitor(final SourceUnit unit, final ClassNode node) {
        return new StaticCompilationVisitor(unit, node);
    }

, которые возвращают пользовательский класс посетителей для каждого из случаев.

Глядя на StaticCompilationVisitor, мы видим:

public class StaticCompilationVisitor extends StaticTypeCheckingVisitor {
    ...
    public void visitClass(final ClassNode node) {
        ...
        super.visitClass(node);
        ...
    }
    ...
}

, другими словами, класс посетителей для CompileStatic расширяет класс посетителей на TypeChecked и, кроме того, visitClass метод (который выполняет реальную работу) в CompileStatic вызовах посетителей super.visitClass(node), где super - класс посетителей для TypeChecked.

Я думаю, это более или менее доказывает это.Поведение CompileStatic на самом деле является надмножеством поведения TypeChecked.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...