Geek Answers Handbook

The correct way to construct an Option object: Option (value) vs Some (value)

What are the advantages and disadvantages of two ways to run Option objects:

1.

 def getAmount: Option[Int] = { val a: Int = 1 Option(a) }

2.

 def getAmount: Option[Int] = { val a: Int = 1 Some(a) }

What should i use?

+5
source share
2 answers

There are two important differences. First, Option will return None if its argument is null:

 scala> val x: Option[String] = Some(null) x: Option[String] = Some(null) scala> val y: Option[String] = Option(null) y: Option[String] = None

This may be useful, but it is not always what you want, and (just as important) it assumes that there is a reasonable chance that the argument may be empty in some cases, which may be misleading.

Some more suitable for cases when you want to create an Option around a value that, as you know, is not equal to zero. Unfortunately, the second difference is that the return type of Some(foo) is Some[Whatever] , not Option[Whatever] , which can be really inconvenient in some situations, when the presence of Some means that you get type errors when you try use None or Option in some positions later. In these cases, you should use Some(foo): Option[Whatever] , which is pretty annoying.

For example, suppose we have a list of strings representing (hopefully) integers, and we want to analyze and sum them up. We want a None if, otherwise, a parsing error and Some(total) . The following is a reasonably reasonable way to do this in one round, using the standard library:

 List("1", "2", "3").foldLeft(Some(0)) { case (acc, item) => for { t <- acc n <- util.Try(item.toInt).toOption } yield t + n }

Except that it does not work, we get an error like:

 <console>:10: error: type mismatch; found : Option[Int] required: Some[Int] t <- acc ^

We can fix this by writing .foldLeft(Some(0): Option[Int]) , but ugh.

This is not a problem in your specific example, because the return type is explicitly Option[Int] , so you do not need to worry about the type of output. In this case, Some(a) is the right choice.

As an additional note, Scalaz provides Some and None constructors to help you avoid type inference problems and noisy solutions like Some(foo): Option[Whatever] :

 scala> import scalaz._, Scalaz._ import scalaz._ import Scalaz._ scala> some(10) res0: Option[Int] = Some(10) scala> none[Int] res1: Option[Int] = None

Both return types are Option , which makes type inference much easier. You can trivially define them yourself if you do not want to use Scalaz:

 scala> def some[A](a: A): Option[A] = Some(a) some: [A](a: A)Option[A] scala> def none[A]: Option[A] = None none: [A]=> Option[A]

If you use them instead of Some and None , you never have to worry about displaying an incorrectly defined type.

To summarize: use Option(foo) only in situations where the argument can be null (which ideally should only be for things like interacting with Java). Use Some(foo) when the value is explicitly specified as Option . If the type being deduced is Some[Whatever] , add an annotation of the type : Option[Whatever] or use something like Scalaz Some .

+18
source

For me, it's just a matter of common sense. Of course, you can imagine a case when you expect something of a certain type like Some and None. But usually the second way looks much more natural: the return type is an option, and the actual implementation is either (x) or None. Technically, from the source code , Option (x) calls the apply() method of the companion object:

 object Option { import scala.language.implicitConversions implicit def option2Iterable[A](xo: Option[A]): Iterable[A] = xo.toList def apply[A](x: A): Option[A] = if (x == null) None else Some(x) def empty[A] : Option[A] = None }

And Some (a) call the apply() method in the case class.

 final case class Some[+A](x: A) extends Option[A] { def isEmpty = false def get = x }

All other methods are the same. The use case with null objects is very well explained in Travis Brown's answer.

0
source

More articles:


All Articles