Scala: Могу ли я объявить публичное поле, которое не будет генерировать геттеры и сеттеры при компиляции?

В Scala, когда вы объявляете val или var, Scala автоматически сгенерирует приватное поле и получатели и сеттеры для вас при компиляции в байт-код.

например.

class myClass {
    val name = "My Name"
}

будет компилироваться для создания эквивалентного

class myClass {
    private string name;
    public string name();
    public void name_$eq(string);
}

Если name() и name_ $eq - это геттеры и сеттеры для имени частной строки.

Я знаю, что вы можете заставить его не предоставлять геттеры и сеттеры для частных полей, объявляя их как private [это] val/var blah, но мне нужно создать публичное поле, которое не генерирует геттеры и сеттеры при компиляции.

Возможно ли это в Scala?

Спасибо

Ответ 1

~~Сгенерированный класс не содержит геттеров или сеттеров, как можно видеть в предоставленном вами образце.~~ Сгенерированные классы не содержат java bean геттеров или сеттеров. Чтобы на самом деле заставить компилятор генерировать методы getX и setX для var, вам нужно аннотировать эту переменную с помощью @BeanProperty.

Если вы хотите, чтобы открытое поле было доступно из java, я думаю, что вам не повезло, к сожалению. По крайней мере, я не видел способ сделать это, используя только scala.

Вы можете выполнить это, смешав scala и java. С классом java, например:

public abstract class JavaClassWithPublicField {
   public String name = "My name";
}

И затем в вашем коде scala наследуйте этот класс:

class ScalaClassWithPubilcField extends JavaClassWithPublicField

Скорее всего, это самый чистый способ сделать это.

Ответ 2

Предположительно, вы хотите, чтобы ваш атрибут был представлен, потому что вы получаете доступ к Java. (Если вы пытаетесь "оптимизировать" ваш байт-код, избавившись от геттера, тогда вы теряете время, VM быстро включит их.) К сожалению для вас, чтобы держать дверь как можно более открытой для будущего улучшения, Scala specs не указывают, как код Scala должен быть переведен в байтовый код. Это означает, что даже если вы найдете трюк, который работает для данной версии Scala, он не гарантирует работу в последующих версиях.

Рекомендуемый подход в этих случаях - написать Java-видимый код на Java, а затем иметь небольшой класс клея, написанный в Scala - что-то вроде ответа, данного @Emil, отлично.