The utility of Options is not in data storage. Options are not used to “store” values - as your intuition clearly can tell, we can use lists to store as many values as we like. The reason why Options are useful is not the same why Lists are useful. Why We Need Options in ScalaĪt this point, you might be thinking why on Earth we need this weird data structure which resembles a list, but it only contains a single value or nothing. There are more methods in the Option data type, but these are the most frequently used. There’s also a get method on Option, which returns the value inside, but beware: if the Option is empty, the method will crash! Finally, the orElse method returns the original Option if non-empty, or the other option otherwise. The getOrElse method returns either the value inside the option, or the default value which we pass as argument.
The isEmpty method checks whether an Option contains nothing. getOrElse ( 99 ) val aChainedOption : Option = anEmptyOption. Since we want to add new functionality to an existing type without being able to modify the source code, the way to go are implicits.Val checkEmpty : Boolean = anOption. So, since it’s not there (yet) we have to come up with a solution ourselves. Personally, I would find such an API for Option very intuitive to use, concise, compact and fully OO. Val converted = myOpt some_? (_.("-")) orNone "unknown" Val converted = if(myOpt.isDefined) .mkString("-") else "unknown"Īpparently, it’s not that hard to put the desired conversion in one line of code, however, using conditional logic to achieve the desired result tempers my enthusiasm considerably. By using other methods of the Option API I could convert this into a one-liner as follows: The good news is, that there is an alternative.
SCALA OPTION CODE
Four lines of code to perform a simple conversion or provide a default value depending whether we are dealing with a Some or a None is quite a lot. This is the only case I can think of where I can associate Scala with boilerplate code. Otherwise we want to provide a default value of “unkown”. To illustrate this let’s consider the following snippet:Ĭase Some(v) => v.("-")īasically, what we want to achieve here is a conversion from Int to a String depending whether the Option is of type Some(Int). When writing Scala code I find myself using this construct quite often. Otherwise, in case it’s a None, I want to provide a default value of the target type Y. Whereas a programmer can express his/her intent in Scala in an extremely concise and compact way I must admit that this is not always true when dealing with Options.ĭepending whether I’m dealing with a Some() a want to convert the value of type X to a value of another type Y. Options provide a very concise way to express whether a variable can have a value or not. Read on to see how easy it is to tailor any kind of existing Scala type to perfectly fit your needs based on an example with Options.
SCALA OPTION HOW TO
This blog explains how to deal with this particular case in an elegant way using implicits. However, it’s usage in certain cases can lead to rather verbose code. Most libraries and applications make use of this handy type. The Scala Option type is key for dealing with variables that can have values or not.
0 kommentar(er)
