Рекурсивная семантика перегрузки в Scala REPL - языки JVM
Просто узнал ответ и подумал об обновлении здесь. Просто нужно сделать следующее.
public class AddressBook: DbContext
{
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.IncludeMetadataInDatabase = false;
}
}
2 ответа
Проблема - то, вследствие того, что интерпретатор чаще всего должен заменять существующие элементы именем, а не перегружать их. Например, я буду часто пробегать экспериментирование с чем-то, часто создавая названный метод test:
def test(x: Int) = x + x
Немного позже скажем, то, что я выполняю другой эксперимент, и я создаю другой названный метод test, не связанный с первым:
def test(ls: List[Int]) = (0 /: ls) { _ + _ }
Это не совершенно нереалистичный сценарий. На самом деле это точно, как большинство людей использует интерпретатор, часто даже не понимая это. Если интерпретатор произвольно решил сохранить обе версии test в объеме, который мог привести к запутывающим семантическим различиям в использовании теста. Например, мы могли бы позвонить test, случайно передача Int вместо List[Int] (не самый неожиданный несчастный случай в мире):
test(1 :: Nil) // => 1
test(2) // => 4 (expecting 2)
Со временем корневой объем интерпретатора быть невероятно нарушенным различными версиями методов, полей, и т.д. Я склонен оставлять свой интерпретатор открытым в течение многих дней за один раз, но если перегрузка как это была позволена, мы будем вынуждены "сбросить" интерпретатор время от времени, поскольку вещи добрались, чтобы также сбивать с толку.
Это не ограничение JVM или компилятора Scala, это - преднамеренное проектное решение. Как упомянуто в ошибке, можно все еще перегрузиться, если Вы в чем-то другом, чем корневой объем. Включение Ваших методов тестирования в классе походит на лучшее решение меня.
REPL примет, копируете ли Вы обе строки и вставляете обоих в то же время.