|
|
|
|
|
by gravypod
3429 days ago
|
|
The first option ins completely unreadable to me. I cannot imagine that ever scaling well. The second option, as I have stated many times in this thread, is far preferable to null. Java does not support it but when it does I will like it. "* No null check, no loops, just very simple easy-to-read bulletproof code. This code cannot generate a NPE at all, ever.*" The NPE isn't the illness, it's the symptom. It's the symptom of a far larger problem in your program: unhandled or otherwise unexpected state. That's why I like the match example. It forces you to expect all of the states of your program. The first example does neither. It hides flow and operation in a single (ever-expanding) line. Far from ideal in any case in my book. As soon as Match is supported in Java I'll change my opinion. Until then I'm stuck. You get nothing better from the Java version in terms of readability. |
|
In Scala, the debate between using fold on an Option or using map and getOrElse is almost as old as the language. The method signature for this is:
That is to say, fold always returns type B, and takes two arguments. The first takes a function returning type B if the option is "empty" (None) and the second takes a function that is called with the contents of the Some. As you can see, it's syntactic sugar for map and getOrElse.