3 ms·
Regarding "It makes code more verbose": while "new JSome<LongSuperclassName>(myValue)" is certainly more verbose than necessary, I still think that the one bit
by limmeau 17y ago
Regarding "It makes code more verbose": while "new JSome<LongSuperclassName>(myValue)" is certainly more verbose than necessary, I still think that the one bit of information "this method returns Foos" vs "this method returns Foos or nothing" is worth documenting. And in a statically typed language, the type system is an obvious place for such documentation.
- pmjordan 17y agoSure, if you're already going to go to the trouble of having type annotations for everything, adding an extra '?' (like in C#) isn't going to break the camel's back. It's the unboxing and wrangling with the returned value that make it more verbose. As far as I can tell the only statically typed languages that stand any chance in terms of terseness are those with sophisticated type inference. In that case, "can return null" or not makes a lot of sense for auto-generated documentation or making it an error to compare the return value to null.
- limmeau 17y agoThere is bound to be some wrangling with the returned value if the case of "something was returned" needs different treatment from "nothing was returned" in the program's design. However, I agree that match perform_foo() with | Some x -> do_something_with x | None -> do_without looks a lot less messy than JOption<Bar> baropt = performFoo(); if(baropt.isNonempty()) { Bar bar = baropt.getValue(); doSomethingWith(bar); } else { doWithout(); } There's just something deeply unsatisfying with a statically typed language that requires so much legalese and boilerplate as Java while still permitting surprising runtime errors in virtually every executable line of the program. Abandoning static types is one approach to the dilemma, trying to plug hole by hole is another.