Timeline for Why does Java have `void` methods?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 26, 2017 at 13:55 | comment | added | JimmyJames |
@cmaster I should probably add that I think to make this work in a Java-like language, you would need to require every class to define a 'null' instance. That way when you e.g. lookup a value in a map, it has something to return. It could even automatically define a null on each type that works like it does today.
|
|
| Apr 26, 2017 at 7:23 | comment | added | cmaster - reinstate monica |
@SargeBorsch I agree with that :-) My objection is against a language without a standard way to express a "please ignore this value". null works fine for this (fine = simple), but standardized optional values with solid semantics are definitely another fine option (fine = safe).
|
|
| Apr 26, 2017 at 5:24 | comment | added | Display Name |
@cmaster an obvious replacement for null is a proper optional type (like, Maybe in Haskell). The problem with nulls in Java is that there's no sane way to immediately decide if a value is nullable in practice or not. This leads to both of: unnecessarily defensive programming (checking for nulls where it's pointless, thereby increasing percentage of poop in the code), and accidental NPEs in production (if forgot to check where it was needed). Yeah, it's partially solved by annotations but they are optional, not always checked, etc. So they won't save you at boundaries with third party code.
|
|
| Apr 25, 2017 at 16:39 | comment | added | cmaster - reinstate monica | I agree to respectfully disagree :-) | |
| Apr 25, 2017 at 15:49 | comment | added | JimmyJames | @cmaster I've pondered this for a while and what I would expect is that if you need a null value (many designs don't) for a class you would implement a singleton object that represents 'no value'. The implementation of this object would depend on the design. Generally I prefer to avoid having nulls anywhere except in local scope (although I do get lazy sometimes.) Rarely, I need some sort of special non-value object and I use this pattern. This really cleans up code because you need no if(foo == null) guard conditions. You are entitled to your opinion, of course, but I respectfully disagree. | |
| Apr 25, 2017 at 10:50 | comment | added | cmaster - reinstate monica |
Well, if null were not part of the language, people would be using all sorts of sentinel values that mean "please ignore this argument/return value, it does not contain any sensible value". The problem with null is not the thing itself, only that it tends to be used incorrectly. I'd wager that this problem would only be exaggerated if the standardized null would be replaced with a myriad of custom solutions, where each implementation would behave differently like silently ignoring usage, or throwing special exceptions instead of a standart null pointer exception, etc.
|
|
| Apr 24, 2017 at 19:14 | comment | added | 8bittree | @marisbest2 Which argument? | |
| Apr 24, 2017 at 17:39 | comment | added | marisbest2 | On a static method the pattern would be to return the argument | |
| Apr 24, 2017 at 17:29 | comment | added | JimmyJames | @Cody Good point, this wouldn't apply to static methods. | |
| Apr 24, 2017 at 17:17 | comment | added | Cody |
I haven't used Java in a while, but is it possible to return this; on a static method? If you do change the language to implicitly return this on void methods, what would happen to static ones?
|
|
| Apr 24, 2017 at 16:36 | history | answered | JimmyJames | CC BY-SA 3.0 |