The Option type in Scala.

Before going to start reading this post, if you are really want to learn Scala from scratch you can refer my previous Post as well, that is one of them this Scala series.

Scala has a standard type named Option for optional values. Such a value
can be of two forms. It can be of the form Some(x) where x is the actual
value. Or it can be the None object, which represents a missing value.
Optional values are produced by some of the standard operations on
Scala’s collections. For instance, the get method of Scala’s Map produces
Some(value) if a value corresponding to a given key has been found, or
None if the given key is not defined in the Map. Here’s an example:

scala> val capitals =
Map(“France” >
“Paris”, “Japan” >
“Tokyo”)
capitals:
scala.collection.immutable.Map[java.lang.String,
java.lang.String] = Map(France >
Paris, Japan >
Tokyo)
scala> capitals get “France”
res21: Option[java.lang.String] = Some(Paris)
scala> capitals get “North Pole”
res22: Option[java.lang.String] = None

The most common way to take optional values apart is through a pattern match. For instance:

scala> def show(x: Option[String]) = x match {
case Some(s) => s
case None => “?”
}
show: (Option[String])String
scala> show(capitals get “Japan”)
res23: String = Tokyo
scala> show(capitals get “France”)
res24: String = Paris
scala> show(capitals get “North Pole”)
res25: String = ?

The Option type is used frequently in Scala programs. Compare this to the
dominant idiom in Java of using null to indicate no value. For example,
the get method of java.util.HashMap returns either a value stored in the
HashMap, or null if no value was found. This approach works for Java, but is
error prone, because it is difficult in practice to keep track of which variables
in a program are allowed to be null. If a variable is allowed to be null,
then you must remember to check it for null every time you use it. When
you forget to check, you open the possibility that a NullPointerException
may result at runtime. Because such exceptions may not happen very often,
it can be difficult to discover the bug during testing. For Scala, the approach
would not work at all, because it is possible to store value types in hash
maps, and null is not a legal element for a value type. For instance, a
HashMap[Int, Int] cannot return null to signify “no element”.
By contrast, Scala encourages the use of Option to indicate an optional
value. This approach to optional values has several advantages over Java’s.
First, it is far more obvious to readers of code that a variable whose type
is Option[String] is an optional String than a variable of type String,
which may sometimes be null. But most importantly, that programming
error described earlier of using a variable that may be null without first
checking it for null becomes in Scala a type error. If a variable is of type
Option[String] and you try to use it as a String, your Scala program will
not compile.

Patterns everywhere .

Patterns are allowed in many parts of Scala, not just in standalone match expressions. Take a look at some other places you can use patterns.

Patterns in variable definitions.

Any time you define a val or a var, you can use a pattern instead of a simple identifier. For example

scala> val myTuple = (123, “abc”)
myTuple: (Int, java.lang.String) = (123,abc)
scala> val (number, string) = myTuple
number: Int = 123
string: java.lang.String = abc

This construct is quite useful when working with case classes. If you
know the precise case class you are working with, then you can deconstruct
it with a pattern. Here’s an example.

scala> val exp = new BinOp(“*”, Number(5), Number(1))
exp: BinOp = BinOp(*,Number(5.0),Number(1.0))
scala> val BinOp(op, left, right) = exp
op: String = *
left: Expr = Number(5.0)
right: Expr = Number(1.0)

Thanks for Reading this blog !!

https://medium.com/analytics-vidhya/java-vs-scala-7ff9eb50141