Scala - ковариантный тип в изменяемых коллекциях

1 Это не похоже на один вопрос, поэтому я должен разделить его дальше:

1. «На самом деле» everything - это ListBuffer[_] со стертым типом параметра. В зависимости от JVM он содержит 32- или 64-битные ссылки на некоторые объекты. Типы ListBuffer[String] и ListBuffer[Any] - это то, что компилятор знает о них во время компиляции. Если он «знает» две противоречивые вещи, то это, очевидно, очень плохо.

2. «Я не вижу проблем, чтобы иметь Integer и String в одном ListBuffer [Any]». Нет проблем с Int и String в ListBuffer[Any], потому что ListBuffer инвариантен. Однако в вашем гипотетическом примере ListBuffer ковариантен, поэтому вы сохраняете Int в ListBuffer[String]. Если кто-то позже получит Int от ListBuffer[String] и попытается интерпретировать его как String, то это, очевидно, очень плохо.

3. «Как я могу сохранить целочисленное значение в коллекции строк в том виде, в каком они пишутся?» Зачем вам делать что-то, что явно очень плохо, как описано выше?

4. «Почему катастрофа ???» Это не будет серьезной катастрофой. Java всегда жила с ковариантными массивами. Это не приводит к катаклизмам, это просто плохо и раздражает.

5. «Почему я должен использовать List (который является неизменным) вместо ListBuffer (который является изменяемым)?» Нет абсолютного императива, который велит вам всегда использовать List и никогда не использовать ListBuffer. Используйте оба, когда это уместно. В 99,999% случаев List, конечно, более подходит, потому что вы используете Lists для представления данных чаще, чем вы разрабатываете сложные алгоритмы, требующие локального изменяемого состояния ListBuffer.

6. «Я нашел много ответов, что изменчивые коллекции должны иметь инвариантный тип, а неизменные коллекции должны иметь ковариантный тип, но почему?». Это неправильно, вы слишком упрощаете. Например, интенсиональные неизменяемые множества не должны быть ни ковариантными, ни инвариантными, а контравариантными. Вы должны использовать ковариацию, контравариантность и инвариантность, когда это уместно. Эта маленькая глупая иллюстрация оказалась неоправданно эффективной для объяснения разницы, может быть, вы тоже сочтете ее полезной.

2 Это одноэлементный тип, как в следующем примере:

scala> val x = "hello"
x: String = hello

scala> val y: x.type = x
y: x.type = hello

Вот более подробное обсуждение мотивации этого.

Я согласен с большей частью того, что говорит @Andrey, я бы просто добавил, что ковариация и контравариантность принадлежат исключительно неизменяемым структурам, упражнение, предлагаемое в книгах, является всего лишь примером, чтобы люди могли понять, но невозможно реализовать изменяемую структуру, которая является ковариантный, вы не сможете его скомпилировать. В качестве упражнения вы можете попробовать реализовать MutableList[+A], вы обнаружите, что это невозможно сделать, не обманывая компилятор, помещая asInstanceOf везде