101–110 of 197 posts
Shameless self plug "Comparing Optionals and Null in Swift, Scala, Ceylon and Kotlin" http://codemonkeyism.com/comparing-optionals-and-null-in-swi...
Tsssk, tssk, you wrote that on the 12th anniversary of the Groovy creator's announcement of the language at http://radio-weblogs.com/0112098/2003/08/29.html
Earlier quoted context omitted.
Exactly, it forces the programmer to think about whether something can be null or not and actually had a behavioural change in my java coding.
Wouldn't it be better to have a non-nullable type, akin to C++'s return by value? That way, instead of forcing the programmer to think, you are removing the problem that they would need to think about.
However the functionality of a null reference type is useful, because it allows a function to return 'no value'. So the goal of an Option type should be to expose the contract for T when there's a value and remove the contract when there's no-value.
The programmer is then explicitly forced to acknowledge the two states that the value could be.
Shameless plug - My C# implementation of Option which is possibly the most complete example out there (at least in C# world):
https://github.com/louthy/language-ext/blob/master/LanguageE...
Earlier quoted context omitted.
This is another off-base point, in my opinion. Sure, it's possible for it to be null, and that isn't great - but the vast majority of null problems come from the user assuming the interface won't give you a null. Something returning an Optional should never return null, so the ambiguity is resolved. Sure, it still could as a bug, but that's actually a pretty rare case. I don't see it being a real problem.
that makes sense. i think an important question here is - what does "return null" in a method which returns Optional do? will it return a null Optional , or will it return a non-null Optional which is empty? sorry to rub it in, but Java needs value types. this whole issue, however maybe irrelevant, does not exist in C#.
some have already commented here that author maybe complains too much (e.g., calling .get() on an Option is a deliberate move, meaning that the developer explicitly took on the risk of that exception. that's very different than implicitly assuming that a regular ref is not null, using it and getting bitten in the ass.). but this one really hurts: "The last flaw with Java's implementation is a bit ironic — It's possib…
Earlier quoted context omitted.
The author is missing the point. Is he? The point is that in Java you are still able to treat x unsafely, while languages with stronger typing do not. E.g. in Haskell, if a function returns a Maybe a , it will always be a Just a or Nothing value. Moreover, such languages allow you to make non-exhaustive matching against all constructors a compiler error. tl;dr: Haskell, Rust, et al. put the burden on the compiler. Ja…
>tl;dr: Haskell, Rust, et al. put the burden on the compiler. Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.) Actually, (much to my disappointment as I'm just learning rust) you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. For such a "safe" strongly-typed language, I'm surprised that so much new rust code do…
Explicit vs implicit. In Rust/Haskell you are forced to do _something_ about the nullability. If you use unwrap/expect/fromJust you are explicitly acknowledging that you want it to panic if it fails.
On the other hand, in Java, you can get an NPE where you didn't expect it because nulls move around easily and there's nothing in the type system to prevent that. That's the difference.
> I'm surprised that so much new rust code does this
Also, in my experience, unwrap() in Rust is mostly confined to irrecoverable errors in applications, and example blog posts (where the focus is on getting something done and not worrying about good error handling).
> defeats a core purpose of rust
What purpose? Whatever unwrap provides is still possible via a match+panic. Which is _more_ explicit, but they're both still explicit.
Earlier quoted context omitted.
>tl;dr: Haskell, Rust, et al. put the burden on the compiler. Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.) Actually, (much to my disappointment as I'm just learning rust) you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. For such a "safe" strongly-typed language, I'm surprised that so much new rust code do…
I completely agree. unwrap() is a huge mistake in Rust. There are brilliant ideas implemented in Rust (primarily the borrow checker) but their advantages seem to be wiped out by the kludge of unwrap.
Earlier quoted context omitted.
that makes sense. i think an important question here is - what does "return null" in a method which returns Optional do? will it return a null Optional , or will it return a non-null Optional which is empty? sorry to rub it in, but Java needs value types. this whole issue, however maybe irrelevant, does not exist in C#.
It's a very simple question to answer: "return null" returns null.
Shameless self plug "Comparing Optionals and Null in Swift, Scala, Ceylon and Kotlin" http://codemonkeyism.com/comparing-optionals-and-null-in-swi...
I've only used the Guava version of Optional, which appears to have a slightly different API than Java 8's. (You can tell there's a Java 8 committee, that's for sure.) The biggest problem I found in applying Optional is that Optional is very much a Haskell-y concept to me, and Java programmers and Haskell programmers don't really overlap much. Therefore, to me, Optional is just a functor like a list or a set. So doin…
> That said, it's pretty rare to need exactly 0 or 1 of something. That's interesting and sort of hard to agree with. I think uniqueness is very often desirable and very often paired with a lack of certainty about existence. "Does a user with this identity exist?" certain is handled properly as a 0-or-1 question, e.g..
Earlier quoted context omitted.
I completely agree. unwrap() is a huge mistake in Rust. There are brilliant ideas implemented in Rust (primarily the borrow checker) but their advantages seem to be wiped out by the kludge of unwrap.
Care to explain why? Whatever unwrap provides can be done with a match+panic. Which is more explicit, but that's just splitting hairs -- unwrap is pretty explicit anyway.
Overall unwrap() isn't good. Really it should be replaced by TODO WRITE ERROR HANDLING in 90% of its cases. That being said there are still good uses for it.
The main _safe_ use for unwrap() I find is when dealing with an iterator of Results/Options (which seems to happen a lot). The pattern:
.filter( |x| x.is_some() )
.map( |x| x.unwrap() )