24:10 "... and evaluate the option just once when you want to retrieve the final value at the end of all your computations -- at the end of the world." Also, 24:30 "... because I'm going to haunt you in your sleep if you ever do this..." This man is quite passionate about Scala!!
The Option substitute for the defensive code doesn't really cover dealing with different error results depending on the "failure combination". How would you go about that using Options and "for" syntax?
@@rockthejvm Thanks for the quick answer! I understand that Option can not represent an error type. However, you argued that in the "defensive code", another (potentially null) value would double the number of cases. But that is only because you generated a different error String for every combination of null/non-null values. With the Option substitute you only generate a single error String no matter which particular value was null. Would there also be an actual substitute to the defensive code using Options?
Sadly making all reference types nullable by default is a huge mistake of design in java and for some reason it got ported over to scala. While it helps to have the option type, this implies that all functions that return nullable types should wrap it by default, otherwise they are unsafe by design, not to mention that arguments can suffer from this problem too. The approach that was taken by kotlin is superior to this one and makes for code that is times more readable and easier to reason about, without introducing boilerplate code.
Experienced Scala guy here. Just watching while cleaning up around the office. All valid in my book.
Love your content! Would be so nice if you could do some more apache spark videos!
24:10 "... and evaluate the option just once when you want to retrieve the final value at the end of all your computations -- at the end of the world." Also, 24:30 "... because I'm going to haunt you in your sleep if you ever do this..." This man is quite passionate about Scala!!
Good one... Thanks for sharing
Could have been noted that the most common way to take a single Option value apart is through a pattern match.
The Option substitute for the defensive code doesn't really cover dealing with different error results depending on the "failure combination". How would you go about that using Options and "for" syntax?
Option really only deals with absent values. For other kinds of errors, check out Either, Try, Validated and other (richer) data structures.
@@rockthejvm Thanks for the quick answer! I understand that Option can not represent an error type. However, you argued that in the "defensive code", another (potentially null) value would double the number of cases. But that is only because you generated a different error String for every combination of null/non-null values. With the Option substitute you only generate a single error String no matter which particular value was null. Would there also be an actual substitute to the defensive code using Options?
Sadly making all reference types nullable by default is a huge mistake of design in java and for some reason it got ported over to scala.
While it helps to have the option type, this implies that all functions that return nullable types should wrap it by default, otherwise they are unsafe by design, not to mention that arguments can suffer from this problem too. The approach that was taken by kotlin is superior to this one and makes for code that is times more readable and easier to reason about, without introducing boilerplate code.