Почему опция [T] в Scala не переводится напрямую в байт-код T?

Question

Одна вещь, которую я не понимаю в Scala, - это то, почему Null все подклассы, несмотря на то, что не прошел тест на замену. Предположительно, это для совместимости с Java, что, я думаю, хорошо, но тогда Scala использует шаблон Option [T].

Это я не понимаю. Опция [T] не дает вам никаких дополнительных гарантий (так как каждый T в любом случае является опцией defacto). Но это также делает в общей сложности 4 состояния:

val a: Option[String] = null
val b: Option[String] = Some(null)
val c: Option[String] = None
val d: Option[String] = Some("A string")

Это кажется неэффективным (из-за байт-кода) и, возможно, даже хуже, чем просто больно Java. Мой вопрос заключается в том, почему Scala не сделал Option [T] особым случаем, который переводит непосредственно в байт-код Java-кода. Все взаимодействие с Java-кодом (использующим ссылки) должно было бы осуществляться с помощью этого Option [T] (который действительно , это именно то, что это). И будет аннотация или что-то подобное, когда метод Scala работает с T, который не может быть None.

Это кажется наиболее правильным, наиболее безопасным и эффективным.

Спасибо

Answer 1

Основная причина для Option - поддержка любого типа , который может быть AnyVal или AnyRef. Scala требует, чтобы AnyVal не мог быть нулевым . Это означает, что параметр типа T не может быть просто установлен равным нулю. Это делает неудобным использование обобщений в библиотеках, таких как библиотека коллекций Scala, без использования Option.

val n: Option[Int] = Some(null) // will not compile

Я полагаю, вы правы, что существует множество возможных оптимизаций для исключения опции , которая может исключить фактическое использование класса на уровне байтового кода. Существует возможность включить агрессивную оптимизацию для компилятора Scala, которая может сделать именно это, но над ней все еще ведется большая работа.

Answer 2

Neil ответ довольно хороший, но я хотел бы добавить еще один фактор. Option не является частью языка, это просто библиотека. Как бы вы реализовали то, что предлагаете?

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

Answer 3

Существует три возможных причины:

1. Scala - это тонкая оболочка, которая только добавляет новые вещи, и они не хотят этого ломать.
2. Они не хотят, чтобы использование библиотек Java было трудной задачей, потому что тогда все аргументы были бы Option [T] вместо T.
3. Им не нужно использовать разделение имен или аннотации для разграничения библиотек, написанных на Scala и написанных на Java (чтобы пометить метод как «необнуляемую ссылку»).

Answer 4

Поскольку Option является нормальным типом, он может расширять черты, использовать логику диспетчеризации нормального метода, вы можете проверить его с помощью isInstanceOf и т. Д.

Вас может заинтересовать Kotlin, который делает в значительной степени то, что вы хотите и должен быть выпущен довольно скоро.