2011-05-30 15 views
11

Me pregunto si la biblioteca estándar es completamente null -free y, de lo contrario, estaría interesado en qué casos de uso razonables existen donde devolver null es preferible a devolver alguna instancia de Option.¿Qué métodos de Scala devuelven null en lugar de una opción y por qué?

+0

El único caso de uso razonable para devolver 'null' es cuando está utilizando una biblioteca que espera que' devuelva 'nulo' de una devolución de llamada como una indicación de" no resultado ". Esto es a menudo un mal necesario cuando se trata de bibliotecas heredadas de Java a partir del código de Scala. –

+0

En general, los métodos de la biblioteca de Scala devolverán la opción o emitirán una excepción si se llaman de forma inapropiada (por ejemplo, cabecera y última en la lista). No conozco ninguno que devuelva nulo. –

Respuesta

5

NamespaceBinding devuelve null para el espacio de nombres local o en el siguiente caso una entrada no definida.

$ scala 
Welcome to Scala version 2.9.0.1 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_24). 
Type in expressions to have them evaluated. 
Type :help for more information. 

scala> (<foo/>).scope.getURI("something") 
res0: String = null 

¿Por qué se trata de utilizar String en lugar de Option[URI], no sé.

+1

Relacionado con 'scala.xml.Elem' que toma un valor de prefijo' String' que se espera que sea 'nulo' para ningún prefijo de espacio de nombres. Una vez más, por qué no es 'Option [String]' está más allá de mí. –

+0

Al menos es constantemente molesto ... –

-1

No puedo pensar en ninguno, así que hice una búsqueda en Google en la API (inurl: scala-lang.org/api return + null) y no pareció dar ningún uso documentado de null.

Puede haber un uso interno som. Las únicas razones por las que se me ocurre hacer eso serían evitar el Some-object extra o una integración fácil con java. Ambos parecen poco probables.

+1

Como Scala no usa 'return' la mayor parte del tiempo, esta búsqueda realmente no atrapará mucho. –

+0

No estaba hablando de retorno en el código, pero regreso en comentario – thoredge

5

El único lugar que he visto null utilizado en la biblioteca estándar son grupos regex opcionales.

scala> val number = """(\d+)(\.\d+)?""".r // matches digits optionally followed by a . and more digits 
number: scala.util.matching.Regex = (\d+)(\.\d+)? 
scala> "12" match { 
    | case number(intPart, decimalPart) => (intPart, decimalPart) 
    | } 
res0: (String, String) = (12,null) 

creo, el razonamiento aquí es que usted no desea utilizar Option[String] para todos los grupos. Esto haría el código innecesariamente torpe, si un grupo no es opcional. Desafortunadamente, no se conoce en tiempo de compilación si un grupo es opcional. Por lo tanto, es Option[String] para todos los grupos o null para grupos que no coinciden.

+2

Me gusta mucho el hecho de que Regex se convierta automáticamente en patrón de coincidencia, y el hecho de que en el 90% de los casos querría un 'String' recto; pero como Scala está casi exento de excepciones raras, puede haber sido una buena idea si usa 'Option [String]' para coherencia. 'La opción [String]' y/o 'List' aparece con frecuencia cuando se analiza Json y no creo que les importara mucho, ya que los usaría para la comprensión. –

+2

@Eugene Consejo: si especifica el tipo, no coincidirá con 'null'. Por ejemplo, 'case number (intPart: String, decimalPart: String)' no coincidirá con la cadena de arriba. –

Cuestiones relacionadas