, Посмотрим, решит ли команда Scala это исправить.

тировать: ошибка, которая вызвала этот вопростеперь исправлено.

В справочнике Scala я могу прочитать (стр. 86):

Интерпретация присваивания простой переменной x = e зависит от определения x. Если x обозначает непостоянную переменную, то присваивание изменяет текущее значение x на результат вычисления выражения e. Ожидается, что тип e будет соответствовать типу x. Если x - это функция без параметров, определенная в некотором шаблоне, и тот же шаблон содержит функцию-установщик x_ = в качестве члена, тогда присваивание x = e интерпретируется как вызов x _ = (e) этой функции-установщика. Аналогично, присвоение f .x = e функции без параметров x интерпретируется как вызов f.x _ = (e).

Так, например, что-то вроде этого работает нормально:

class A {
  private var _a = 0
  def a = _a
  def a_=(a: Int) = _a = a
}

Я могу тогда написать

val a = new A
a.a = 10

Но если я определю класс следующим образом, добавив параметр типа к методу a:

class A {
  private var _a = 0
  def a[T] = _a
  def a_=(a: Int) = _a = a
}

тогда это больше не работает; Я получаюerror: reassignment to val если я напишуa.a = 10, Как ни странно, он все еще работает без параметра типа и списка неявных параметров, например.

Можно утверждать, что в этом примере параметр типа не очень полезен, но при разработке DSL было бы здорово вызвать метод setter, даже если у метода get есть параметры типа (и, между прочим, добавление параметров типа в setter). разрешено и работает нормально).

Итак, у меня есть три вопроса:

Есть ли обходной путь?Следует ли считать текущее поведение ошибкой?Почему компилятор принудительно применяет метод получения, позволяющий использовать синтаксический сахар для метода установки?

ОБНОВИТЬ

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

Я проектирую GUI с помощью SWT в Scala и получаю огромное удовольствие, используя Дейва Орма.XScalaWT, что значительно уменьшает объем необходимого кода. Вот пример из его сообщения в блоге о том, как создать SWTComposite который преобразует ° C в ° F градусов:

var fahrenheit: Text = null
var celsius: Text = null

composite(
  _.setLayout(new GridLayout(2, true)),

  label("Fahrenheit"),
  label("Celsius"),

  text(fahrenheit = _),
  text(celsius = _),

  button(
    "Fahrenheit => Celsius",
    {e : SelectionEvent => celcius.setText((5.0/9.0) * (fahrenheit - 32)) }
  ),
  button(
    "Celsius -> Fahrenheit",
    {e : SelectionEvent => fahrenheit.setText((9.0/5.0) * celsius + 32) })
  )
)

Аргумент для каждого из методов создания виджетов имеет тип(WidgetType => Any)*с несколькими полезными неявными преобразованиями, которые, например, позволяют напрямую указывать строку для виджетов, которые имеютsetText() метод. Все функции конструктора импортируются из одноэлементного объекта.

В конце я хотел бы иметь возможность написать что-то вроде этого:

val fieldEditable = new WritableValue // observable value

composite(
  textField(
    editable <=> fieldEditable,
    editable = false
  ),
  checkbox(
    caption = "Editable",
    selection <=> fieldEditable
  )
)

Это связало бы редактируемое свойство текстового поля с выбором флажка через переменную WritableValue.

Первое: именованные аргументы здесь не применимы, поэтому строкаeditable = false должен прийти откуда-то. Итак, наряду с методами конструирования виджетов в объекте-одиночке я мог бы написать концептуально:

def editable_=[T <: HasEditable](value: Boolean) = (subject: T) => subject.setEditable(value)

... но это работает, только если геттер также присутствует. Отлично: мне все равно нужен геттер для реализации привязки данных с помощью <=>. Что-то вроде этого:

def editable[T <: HasEditable] = new BindingMaker((widget: T) => SWTObservables.observeEditable(widget))

Если бы это сработало, жизнь была бы хорошей, потому что я могу определить <=> в BindingMaker и использовать этот приятный синтаксис. Но, увы, параметр типа на получателе нарушает установщик. Отсюда мой первоначальный вопрос: почему этот простой параметр типа влияет на то, решит ли компилятор продолжить использование синтаксического сахара для вызова метода установки?

Надеюсь, теперь это станет понятнее. Спасибо за чтение…

Ответы на вопрос(1)

Ваш ответ на вопрос