Почему MPI считают более твердой, чем общая память и Erlang, который рассматривают легче, когда они - оба передача сообщений?

Статический метод определяется не в контексте объекта, а в контексте класса. Вы можете быть смущены присутствием this в статическом методе Groovy. Тем не менее, это только синтаксический сахар, который в конечном итоге заменяет this.name на Animal.class.name.

Если вы скомпилируете класс Animal из вашего примера с включенной статической компиляцией, вы увидите, что он компилируется в следующий эквивалент Java (результат после декомпиляции файла .class ):

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//

import groovy.lang.GroovyObject;
import groovy.lang.MetaClass;
import org.codehaus.groovy.runtime.DefaultGroovyMethods;

public class Animal implements GroovyObject {
    public Animal() {
        MetaClass var1 = this.$getStaticMetaClass();
        this.metaClass = var1;
    }

    public static Object echo() {
        DefaultGroovyMethods.println(Animal.class, Animal.class.getName());
        return null;
    }
}

Вы можете видеть, что следующая строка в методе echo:

DefaultGroovyMethods.println(Animal.class, Animal.class.getName());

работает непосредственно с именем класса Animal. Таким образом, с точки зрения метода echo, не имеет значения, сколько классов его расширяют. Пока эти классы вызывают метод echo, определенный в классе Animal, вы всегда будете видеть Animal напечатанным в результате.

1144 И даже больше. Если вы используете следующий скрипт конфигурации компилятора:

config.groovy

withConfig(configuration) {
    ast(groovy.transform.CompileStatic)
    ast(groovy.transform.TypeChecked)
}

и затем скомпилируете скрипт (назовем его script.groovy ]) используя эту опцию конфигурации с помощью следующей команды:

groovyc --configscript=config.groovy script.groovy

, после декомпиляции файла .class вы увидите нечто подобное:

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//

import groovy.lang.Binding;
import org.codehaus.groovy.runtime.InvokerHelper;

public class script extends groovy.lang.Script {
    public script() {
    }

    public script(Binding context) {
        super(context);
    }

    public static void main(String... args) {
        InvokerHelper.runScript(script.class, args);
    }

    public Object run() {
        Animal.echo();
        return Animal.echo();
    }
}

Вы Можно видеть, что даже если вы вызвали Dog.echo() и Cat.echo() в своем скрипте Groovy, компилятор заменил эти вызовы двойным вызовом Animal.echo(). Это произошло потому, что вызов этого статического метода в любом другом подклассе не имеет никакого значения.

Возможное решение: применение двойной диспетчеризации

Есть один способ получить ожидаемый результат - переопределить статический метод echo в классах Dog и Cat. Я могу предположить, что ваш реальный метод может делать что-то большее, чем примерный метод echo, который вы показали выше, поэтому вам может потребоваться вызвать метод super echo из родительского класса. Но ... есть две проблемы: (1) вы не можете использовать super.echo() в статическом контексте, и (2) это не решает проблему, потому что родительский метод все еще работает в контексте класса Animal. '

Чтобы решить проблему такого рода, вам может понадобиться имитировать технику, называемую double dispatch . Вкратце - когда у нас нет информации о вызывающем объекте в вызываемом методе, давайте разрешим вызывающему передать эту информацию с помощью вызова метода. Рассмотрим следующий пример:

import groovy.transform.CompileStatic

@CompileStatic
class Animal {
    // This is a replacement for the previous echo() method - this one knows the animal type from a parameter
    protected static void echo(Class clazz) {
        println clazz.name
    }

    static void echo() {
        echo(Animal)
    }
}

@CompileStatic
class Dog extends Animal {
    static void echo() {
        echo(Dog)
    }
}

@CompileStatic
class Cat extends Animal {
    static void echo() {
        echo(Cat)
    }
}

Animal.echo()
Dog.echo()
Cat.echo()

Это может звучать как шаблонное решение - для этого требуется реализация метода echo в каждом подклассе. Тем не менее, он инкапсулирует логику echo в методе, который требует параметра Class, поэтому мы можем позволить каждому подклассу вводить свой конкретный подтип. Конечно, это не идеальное решение. Это требует реализации метода echo в каждом подклассе, но другого альтернативного пути нет. Другая проблема заключается в том, что это не мешает вам звонить по телефону Dog.echo(Animal), что вызовет тот же эффект, что и вызов по телефону Animal.echo(). Этот подход с двойной диспетчеризацией больше похож на введение сокращенной версии метода echo, в которой для простоты используется общая реализация статического метода echo.

Я не знаю, решит ли такой подход вашу проблему, но, возможно, он поможет вам найти окончательное решение.