Let us first tell me the discussion result. I am converted from an option hater to a lover, at least not that hate. The reason I hate option is the fact that I have to type “Some” every time and it is, to me, a redundant. I can use C# NULL to check if a variable is being set or not. Today I found out I was wrong, the option is a better way to handle this situation. It forces me to pay attention to check the value. Do you still remember the last time you encounter null exception? I guess not long time ago, right? Let us start with a C# sample with a string type variable.
string str = read_string(); //a function return a string type value
if (str.Length < 10) then Console.WriteLine(“less than 10”) else “long string… “
Seems everything is perfect until you realize the str can be null! L So you have to check str != null first and then perform the real work. If you forget at one place, a monster will be staring at you in the dark.
Let us look at the F# version:
let str = read_string() // return a string option to indicate the return value can be an uninitialized value
match str with
| Some(data) -> printfn “good, we got value and we can process…”
| None -> printfn “what happened, call IT right now!”
We still need to write match and make decision about if the value is None or not, but at least this let you pay attention. Comparing to the C#'s implicit NULL approach, I start to like this way more. It is true that some people still prefer the C# version which puts the check everywhere, but if you write a SDK and expose it to end user, do you expect that guy’s code has a snickering monster? J
Also the option avoid the reference type's NULL value, this NULL value is not a valid value in the problem space. For example, if we use the string to represent first name, what is NULL mean for a people's name? This implicit value give us tons of trouble and increase the complexity of the program because you have to check the NULL everywhere. Why not using an option and make your problem space clean?