¿Por qué la opción [T] de Scala no se traduce directamente a un T en bytecode?

Question

Una cosa que no entiendo acerca de Scala, es por qué Null subclasifica todo, a pesar de no pasar la prueba de sustitución. Presumiblemente, esto es para la compatibilidad con Java, lo cual está bien, supongo, pero luego Scala empuja el patrón Option [T].

Esto no lo entiendo. Una Opción [T] no le da ninguna garantía adicional (ya que cada T es una Opción de hecho de todos modos). Pero también hace un total de 4 estados:

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

Esto parece ineficiente (POV de un código de bytes) y tal vez incluso peor que el dolor de Java. Cuál es mi pregunta, por qué Scala no hizo de la Opción [T] un caso especial que se traduce directamente en una T. de byte de Java. Toda la interfaz con el código de Java (que usa referencias) tendría que ser a través de esta Opción [T] (que realmente , es exactamente lo que es). Y habría una anotación o algo así, para cuando un método de Scala funciona con una T que no puede ser Ninguna.

Esto parece ser el más obviamente correcto, el más seguro y el más eficiente.

Gracias

Answer 1

Hay tres posibles razones:

1. Scala es una envoltura delgada, que sólo añade cosas nuevas y no quieren romper eso.
2. No quieren hacer que las bibliotecas de Java sean un fastidio para usar, ya que todos los argumentos serían la Opción [T] en lugar de T.
3. No quieren tener que usar nombres manipulados o anotaciones para diferenciar bibliotecas escritas en Scala y escritas en Java (para marcar que un método toma una "referencia no nulo").

Answer 2

La razón principal para la opción es apoyo del Cualquier tipo que puede ser una AnyVal o AnyRef. Scala requiere que AnyVal no puede ser nulo. Esto significa que un parámetro de tipo T, simplemente no se puede establecer en nulo. Esto hace que sea difícil usar genéricos en bibliotecas como la biblioteca de colecciones scala sin algo como Option.

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

creo que tienes razón en que hay muchas optimizaciones posibles para eliminar la opción que puede eliminar el uso real de la clase a nivel de código de bytes. Existe una opción para activar optimizaciones agresivas para el compilador de Scala que puede hacer justamente eso, pero todavía se está trabajando intensamente.

Answer 3

Debido Option es un tipo normal, se puede extender rasgos, utilizar la lógica normal método de envío, se puede comprobar con isInstanceOf, etc.

Usted puede estar interesado en Kotlin, que does pretty much what you want y debe ser puesto en libertad muy pronto.

Answer 4

Neil La respuesta es bastante buena, pero me gustaría añadir otro factor. Option no es parte del idioma, es solo una biblioteca. ¿Cómo implementarías lo que sugieres?

Además, aunque no creo que esto sea tan importante, puede reflejar el tipo de un Option, que simplemente no sería el caso si solo se almacenara como T.