3 ms·
To me java.util.Optional is a crutch; an afterthought. I think it would never come to exist if nullability was done right to begin with. Native approach feels c
by V-2 8y ago
To me java.util.Optional is a crutch; an afterthought. I think it would never come to exist if nullability was done right to begin with. Native approach feels cleaner... to me, of course. For starters - in the context of the quoted code example - what sense does it make to have to allocate a new object (via Optional.ofNullable) every single time parseAndInc calculation is performed?? Wrapper types always involve overhead... perfectly avoidable with a language-level, as opposed to library-level, implementation
- Sharlin 8y agoOptional/Option/Maybe is the proper way to implement "may not exist". Null is a crutch and language features that try to make it more reasonable to use are crutches on top of crutches. But I agree that in a language that already has null and can't get rid of it, Optional cannot ever be as useful as in a language that was designed properly in the first place. Wrapper types currently incur overhead in Java. If/when value types are finally implemented, this overhead will become negligible. In languages such as Rust and C++, Optional is already a zero-cost abstraction. From a type theoretic point of view it's clear that Optional has a monad structure, and all the usual combinators make perfect sense for it and are actually a joy to use in languages that support them, including Java. After all, it's perfectly isomorphic to a list with either 0 or 1 elements.