4 ms·
> This returns the zero value of the value type in the map if the key doesn't exist in the map. Wow, that's quite horrible (for a static language, anyway). So
by Dewie 12y ago
> This returns the zero value of the value type in the map if the key doesn't exist in the map.
Wow, that's quite horrible (for a static language, anyway). So if my map returns `0`, I can't really be sure whether that is the zero-value (no value at this key), or that the value that I queried actually is `0`.
> This returns true or false in ok based on whether the value exists, zero value for foo if it doesn't exist.
Better, but still unnecessarily error-prone.
> however, go does have the compilation requirement that the ok value gets used somehow, or it'll give you an unused variable compilation error.
OK, I can see how that could alleviate the problem in practice: maybe in most contexts, there aren't anything more sensible to use the `ok` variable for than to check its value. In that case, the programmer will be alerted if he tries to use the `foo` variable without checking `ok` first.
- ajuc 12y ago> Wow, that's quite horrible (for a static language, anyway). So if my map returns `0`, I can't really be sure whether that is the zero-value (no value at this key), or that the value that I queried actually is `0`. Replace "0" with null, and it's no different from Java maps.
- Dewie 12y agoI think there is a difference, and for the worse: `0` is a perfectly valid integer value which can be used like any other value. `null` is a valid reference value, but is invalid as far as dereferencing goes; refer NullPointerException. `0` has more potential for propagating through the program, and being erroneously used as a valid map value, while it should really be treated like a sentinel value by the program (no-value-in-map). A reference which is assumed to be valid can only propagate through the program to the point where it is dereferenced, in which case the erroneous assumption will be challenged. It seems like the strong/weak typing distinction: one value can be used freely like any other value, since that is what it is. The other can only be used as a regular value to a degree: it can be passed around, but not actually used.
- ajuc 12y agoBTW, there's one more gotcha with java maps: public static void main(String[] args) { Map<String, String> testHashMap = new HashMap<String, String>(); Map<String, String> testTreeMap = new TreeMap<String, String>(); testHashMap.put(null, "foobar"); testTreeMap.put(null, "foobar"); System.out.println(testHashMap.get(null)); System.out.println(testTreeMap.get(null)); } This will throw NullPointerException at the last line :) For hashmaps it works, for treemaps not. Happened on production in my previous company (we used map2.get(map.get(...)) and used null rturned from the inner map to get the default value from the outer. Then we changed to tree maps to keep order when displaying the maps...
- NateDad 12y agoThis is one nice thing about go maps... They won't panic if you try to access a null map, they just return the zero value (and false). var m map[int]int = nil a, ok := m[1] // returns 0, false
- Dewie 12y agoThat doesn't seem nice if the map wasn't supposed to be nil (if you assume that failing fast on buggy behaviour is good). But I guess you might want to, on purpose, instantiate and use a map which is nil?
- NateDad 12y agoWhat's the difference between a nil map and a non-nil but empty map? You asked if the map had a value for your key, and it said no.
- Dewie 12y ago> What's the difference between a nil map and a non-nil but empty map? A nil map is the absence of a map. An empty map is an empty map. The distinction is clear.