Hey, in this section, we're going to go in-depth into option. We can think as option as a type of collection that has zero or one element, unlike list, which can hold many elements, option is only going to be at most one. Like other collections we've seen, option is parameterized by the type of the elements. We see types like Option[Int], where Int is the type of the optional integer value. Option[Boolean] is an option that may hold a Boolean, but it may not. The option value can be either none, which is the case indicates there is no value or it can be some which holds the value. On option, we have all the methods that we used to call on collection map, filter, flatMap, foldLeft, contains etc. Let's see an example of option in use. We're going to return to our address book example and modify the contact type so that we can store an optional email to each contact. That means a contact can have zero or one email address. The first thing to do here is to change the contact case class and we're going to add this field, maybeEmail, which has the type Option[String], the option indicating zero or one elements and string is the type we're using to represent emails. Now, let's create some contact. I have Alice here and Alice has an email address, so we give her email address wrapped up in some. Bob does not have an email address, so for that field, we use none. You will notice that we called the email field, maybeEmail, and this is a fairly common practice in Scala, which is to name optional fields with a maybe prefix. We can also pattern match on option as shown on the slide as option has two cases, some and none. That's what we use in the pattern match. Here we're looking for an email address that ends in the Scala domain for the Some case we check if the email address meets our criteria and for the None case, because there is no email address, the result is false. Let's have a look at some of the other methods that are defined an option. There's a map method, an option which works just the same way as map on other collections. It transforms the value within the collection. Now an option can have zero or one value, what map is going to do is transform that value. If it exists and if there is no value, then nothing happens. Another very useful method on option is getOrElse. getOrElse will get the value inside an option if there is one, and if there is no value inside the option, it returns a value that we pass as a parameter to getOrElse. Here's an example that uses both of them. What we tried to do in this method here is calculate the length of the email in contact. What we first do is call map to get the size of the email, if one exists, then we getOrElse to get that size if it exists and if not, we return zero. zip is another very useful method. zip combines two optional values into one that is, it takes one option and another option, if they both have values, you get both those values inside a tuple. If one of those options or both have no value, then the result is none. Have an example here where we have Alice and Bob and we're zipping together their emails. Now, because Bob has no email in this case, the result will be none. We have already seen that some methods on the collection classes return option. For example, the find method returns an option where the none case indicates that we did not find the value we looking for. The get method on Map also returns an option for the same reason. There are some other methods we haven't seen yet that also return option. One example is headOption on List. Remember, the head method on list throws an exception if there is no value. headOption is a bit safer because it doesn't return an exception, instead, it returns an option with the none case indicating there is no head value. Here's an example of its use. In this method, sendNotification, we're trying to send a message to a contact. What are we going to do is first send a message to their phone if they have a phone and if they don't, we'll try to send a message to their email. We headOption here to get their first phone number. If there is a phone number, then we send an SMS to it. If there is no phone number, we then go and try the email with the same logic. If you've used other programming languages such as JavaScript or Java, you may have come across the use of a concept called null to model optional values. This is sometimes called Nil in other languages. Scala has a null value as well, but we don't use it to model optional values. It's there to interfere with Java and we shouldn't use it in programs that are pure Scala code. We've got a lot of experience as an industry with using null, and the general consensus is that it is a mistake. It leads to very hard to track down errors in code. Option is much safer and is usually preferred in all cases in Scala. That's it for option. To summarize, option can be used to model optional values when a value may or may not be available. There are two cases to option, some for holding a value and none to indicate that no value is available. Option has many of the methods that are available on the general collection classes such as map and flatMap, as well as some methods that are unique to option such as getOrElse. Some collection operations also return options, such as find and headOption. We should prefer using option to using null to model optional values. A lot of experience has shown that null is a mistake and leads to hard to fix bugs.
