Timeline for Is a new Boolean field better than a null reference when a value can be meaningfully absent?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 27, 2019 at 20:30 | comment | added | GalacticCowboy | @FrankHopkins C# 8 is moving that direction, so Java might get it within our lifetimes. | |
| Feb 27, 2019 at 10:47 | comment | added | Christian Hackl | @FrankHopkins: You don't need the shift to "nothing is nullable", you need the shift to "nobody makes nulls because why should they?". Of course, this may never happen if the standard library itself doesn't lead by example. | |
| Feb 27, 2019 at 10:37 | comment | added | Frank Hopkins | @ChristianHackl I'd totally jump the Optional train if any of the next Java versions would shift the paradigm from everything is nullable to nothing is nullable and you need an optional where you want "null". I don't see this happening any time soon though. And with what we got, I find Optionals in reality get more in the way than help (in most real life Java projects). | |
| Feb 27, 2019 at 5:28 | comment | added | Christian Hackl | @FrankHopkins: It may be that the Java community just needs a little paradigm shift, which may yet take many years. If you look at Scala, for example, it supports null because the language is 100% compatible to Java, but nobody uses it, and Option[T] is all over the place, with excellent functional-programming support like map, flatMap, pattern matching and so on, which goes far, far beyond == null checks. You are right that in theory, an option type sounds like little more than a glorified pointer, but reality proves that argument wrong. | |
| Feb 26, 2019 at 21:03 | comment | added | Cubic | @FrankHopkins It's not pointless at all. Just treat the presence of any null anywhere as a bug. Any place where you explicitly assign null? Bug. Any place where you use an external API that doesn't conform to this without checking its result? Bug. | |
| Feb 26, 2019 at 20:40 | comment | added | Alexander | @FrankHopkins Yeah, although FindBugs has filtering (either in an XML config, or via Java annotations) that you can use to demarcate "legacy" code, for which you can ignore the warnings. That way, you can start incrementally improving the code base by writing "good" new code, checked by FindBugs, without failing builds because legacy code doesn't pass FindBugs. | |
| Feb 26, 2019 at 20:37 | comment | added | Frank Hopkins | @Alexander but you need to convert the code base first before any analysis tool can hard-alert, way too much effort for the benefit it gives. (Not to mention convince every new member it's a good idea). | |
| Feb 26, 2019 at 20:29 | comment | added | Alexander | @FrankHopkins Checking isPresent is almost always a code smell, in my experience, and a pretty reliable sign that the devs who are using these optionals are "missing the point". Indeed, it gives basically no benefit over ref == null, but it's also not something you should be using often. Even if the team is unstable, a static analysis tool can lay down the law, like a linter or FindBugs, which can catch most cases. | |
| Feb 26, 2019 at 20:23 | comment | added | Frank Hopkins | @Alexander but in my world teams are also not thaaat stable and there is quite some legacy code and external dependencies. If you have a private project with full control or a very fixed team you may gain more from it by using it via convention, but for me even that feels more like an attempt to turn the language into something it is not. | |
| Feb 26, 2019 at 20:22 | comment | added | Frank Hopkins | @Alexander yes it does have nice features. I've tried to use Optionals in existing code bases, but those features were absolutely rarely used, and "normal" checks with "isPresent" give nearly no benefit over == null checks; the main benefit of knowing what can and cannot be null is imho void because not supported this way by the language; afte all it was always more hassle than benefit and I'm now rather using annotation that goes the other way. For me this is now the only logical way given the language design. | |
| Feb 26, 2019 at 20:15 | comment | added | Alexander | @FrankHopkins It's a shame that nothing in Java prevents you from writing Optional<Date> lastPasswordChangeTime = null;, but I wouldn't give up just because of that. Instead, I would instill a very firmly held team rule, that no optional values are ever allowed to be assign null. Optional buys you too many nice features to give up on that easily. You can easily assign default values (orElse or with lazy evaluation: orElseGet), throw errors (orElseThrow), transform values in a null safe way (map, flatmap), etc. | |
| Feb 26, 2019 at 20:07 | comment | added | Frank Hopkins | @MatthieuM. within languages that have null as a valid value globally, I find Optionals rather pointless and getting in your way more than helping, as a) the optional itself maybe null and b) even if something does not return an optional it could be null and just not be designed by the guy who likes Optionals. For those languages a mechanism like Nonnull annotation I find preferable as it doesn't try (and fail) to impose the reverse principle onto the language than it was designed with. | |
| Feb 26, 2019 at 18:38 | comment | added | Zipp | Came here to connect with Optional as well. I'd encode this as a type in a language which had them. | |
| Feb 26, 2019 at 11:22 | comment | added | Matthieu M. | There's Optional in java too; the meaning of a null Optional being up to you... | |
| Feb 26, 2019 at 8:17 | history | answered | dasmy | CC BY-SA 4.0 |