问题
Scala's Option class has an orNull
method, whose signature is shown below.
orNull [A1 >: A](implicit ev : <:<[Null, A1]) : A1
I'm bewildered by the implicit thing. Would somebody please explain how it can be used, ideally with an example?
回答1:
scala> Some(1).orNull
<console>:10: error: could not find implicit value for parameter ev: <:<[Null,Int]
Some(1).orNull
^
scala> (None : Option[Int]).orNull
<console>:10: error: could not find implicit value for parameter ev: <:<[Null,Int]
(None : Option[Int]).orNull
scala> Some("hi").orNull
res21: java.lang.String = hi
scala> Some(null : String).orNull
res22: String = null
scala> (None : Option[String]).orNull
res23: String = null
To explain the implicit thing: orNull is a way of getting back from the Some|None idiom to Java's value|null idiom (which is, of course, bad). Now only AnyRef values (instances of classes) can accept a null value.
So what we would have liked is def orNull[A >: Null] = ....
. But A is already set and we don't want to restrict it in the definition of the trait. Therefore, orNull expects an evidence that A is a nullable type. This evidence is in the form of an implicit variable (hence the name 'ev')
<:<[Null, A1]
can be written as Null <:< A1
seeing it like this, it is similar to 'Null <: A1'. <:< is defined in Predef as well as the method that provides the implicit value named conforms
.
I think the use of A1 is not strictly required here and is because orNull uses getOrElse (where the default given can be a super type of A)
scala> class Wrapper[A](option: Option[A]) {
| def orNull(implicit ev: Null <:< A): A = if(option.isEmpty) null else option.get
| }
defined class Wrapper
scala> new Wrapper(Some("hi")).orNull
res18: java.lang.String = hi
回答2:
orNull
purpose is first of all in ensuring compatibility of Option
with Java. Though usage of null
is discouraged in Scala, some interfaces may expect to get nullable references.
orNull
has a straightforward implementation:
def orNull[A1 >: A](implicit ev: Null <:< A1): A1 = this getOrElse null
According to this, null
will be returned not only for boxed nulls (Some(null)
), but also for None
(e.g., if you call None.get
, exception will be thrown).
Implicit parameter checks, if the boxed value is nullable.
Good usage example can be found right in the comments to orNull:
val initialText: Option[String] = getInitialText
val textField = new JComponent(initialText.orNull,20)
回答3:
Remember that in Scala primitive types and reference types are unified - but only reference types are nullable. The implicit simply allows the compiler to confirm that A1 is a reference type.
回答4:
To understand why it is useful, IttayD provided a nice explanation:
So what we would have liked is def
orNull[A >: Null] = .....
But A is already set and we don't want to restrict it in the definition of the trait. Therefore, orNull expects an evidence that A is a nullable type. This evidence is in the form of an implicit variable (hence the name 'ev')
In summary, type constraints are useful when you want have methods (eg orNull
) on a generic class (eg Option
) with more specific constraints (eg Null <: A <: Any
) than on the class itself (eg A <: Any
).
This is another "feature" that is not built into the language but comes for free thanks to implicit parameters and variance annotations of type parameters. To understand this, look at the definition of <:<
:
// from Predef
sealed abstract class <:<[-From, +To] extends (From => To)
implicit def conforms[A]: A <:< A = new (A <:< A) {def apply(x: A) = x}
For
scala> Some(1).orNull
<console>:10: error: could not find implicit value for parameter ev: <:<[Null,Int]
Some(1).orNull
the compiler looks for an implicit value of type <:<[Null, Int]
and will find the method def conforms[A]: A <:< A
. So there has to be an A
for which <:<[A, A]
conforms to <:<[Null, Int]
. There is no A
for which this holds and as a result the compiler will complain about the missing implicit value.
However, for
scala> Some("hi").orNull
res21: java.lang.String = hi
we are lucky. Now, the compiler tries to find an A
for which <:<[A, A]
conforms to <:<[Null, String]
. This works for A = String
, because Null
is a subtype of String
and the From
type parameter of the class <:<
is defined as contravariant).
As mentioned, the most intuitive way to think about type constraints is reading it like a type bound (i.e. reading it as Null <: Int). Null
does not conform to Int
and there is no implicit value for <:<[Null, Int]. On the other hand, Null
does conform to String
and the compiler will find the implicit parameter.
By the way, here is another related answer.
回答5:
Re : 'how' is this used - one place we are finding this useful is when dealing with java api mappings where null
is commonplace, e.g. on jdbc prepared statements to nullable sql columns. The Option
al internal model fields can be mapped:
stmt.setDate("field", myModel.myDateField.orNull)
Instead of the more verbose:
stmt.setDate("field", myModel.myDateField.getOrElse(null))
来源:https://stackoverflow.com/questions/4467601/please-explain-use-of-options-ornull-method