So at the end , to summarise, If you are obsessed with functional programming & lambdas, go for optional, or else we should use the traditional way of coding style.
As per rule 6 we should not use optional in collection. Then if fetch data from database and get value as null in a collection reference to the method. Then we should not use optional right. Then again we have to use null check. What is the point of creating optional then? Any suggestions on this.
I feel like the object-oriented way to implement a ‘field that may not need to be stored in all objects that fulfill this interface’ would be defining a separate class of objects that don't store it, and implementing the interface with a method that returns whatever it needs to return there, such as Optional.empty().
For completeness, this question was a response to the scenario sketched at 30:45. I now understand that the speaker probably meant exactly the pattern I was thinking of with the term ‘null object pattern’: one class that has methods that do things using the value of the field and another class that implements those methods to do whatever is right when the field is not applicable.
I question for the geeks: in 28:00, I can't see the benefit of the second map (.map(Optional::of)) why is it included? in which use case is it significant.
Because we want the return value to be an optional as well. Without the 2nd map, orElse would return a BigDecimal since we are dealing with Optional. But the 2nd map turns that into Optional so when we call orElse we end up with Optional which is what we want
A lot of the pain of having to deal with Optionals would be eliminated entirely if only javac was capable of performing proper NULL analysis. Or take a page from functional languages: String? myvar; //
@@pockpicket9360 I think it just syntax sugar.. orElse... orElseThrow etc.. you can just replace all that with the old null testing... if(x==null) throw new MyException() if (x==null) x="default" etc. Am I missing something?
@@bernardobuffa2391 Yes, you are. Thing is, I don't want to check for null all the time. It's something that shouldn't be necessary. With Optionals I can respond to null values in a much more elegant way by just adding .orElse, .orElseGet or .orElseThrow. Checking for null is clunky, ugly and really old-fashioned.
Very informative and well-presented. Thanks!
Best walk-through material that I could find in the internet!
So at the end , to summarise, If you are obsessed with functional programming & lambdas, go for optional, or else we should use the traditional way of coding style.
Optional.get -> no arg Optional.orElseThrow
As per rule 6 we should not use optional in collection. Then if fetch data from database and get value as null in a collection reference to the method. Then we should not use optional right. Then again we have to use null check. What is the point of creating optional then? Any suggestions on this.
Use optional as return value for methods, as mentioned in 35:45
I feel like the object-oriented way to implement a ‘field that may not need to be stored in all objects that fulfill this interface’ would be defining a separate class of objects that don't store it, and implementing the interface with a method that returns whatever it needs to return there, such as Optional.empty().
Would writing it that way feel out of place in Java?
For completeness, this question was a response to the scenario sketched at 30:45. I now understand that the speaker probably meant exactly the pattern I was thinking of with the term ‘null object pattern’: one class that has methods that do things using the value of the field and another class that implements those methods to do whatever is right when the field is not applicable.
Very informative. Thank you
I question for the geeks: in 28:00, I can't see the benefit of the second map (.map(Optional::of)) why is it included? in which use case is it significant.
Because we want the return value to be an optional as well.
Without the 2nd map, orElse would return a BigDecimal since we are dealing with Optional.
But the 2nd map turns that into Optional so when we call orElse we end up with Optional which is what we want
So many places not use were mentioned but where to use optional then ?
He says, you should never return null. Make return types typesafe with Optional
i guess this is why rust uses unrwap() instead of get()
Where Optional violates monad laws?
A lot of the pain of having to deal with Optionals would be eliminated entirely if only javac was capable of performing proper NULL analysis.
Or take a page from functional languages:
String? myvar; //
You're talking about safe navigation operator.
By the way you can use annotations like @Nullable and @NonNull.
just horrible stuff.. will never use this monstruosity... Long live the null
It's extremely useful in some cases.
Most modern languages have this concept
it's probably one of the most usefull java feature
@@pockpicket9360 I think it just syntax sugar.. orElse... orElseThrow etc.. you can just replace all that with the old null testing... if(x==null) throw new MyException() if (x==null) x="default" etc. Am I missing something?
@@bernardobuffa2391 Yes, you are. Thing is, I don't want to check for null all the time. It's something that shouldn't be necessary. With Optionals I can respond to null values in a much more elegant way by just adding .orElse, .orElseGet or .orElseThrow. Checking for null is clunky, ugly and really old-fashioned.