3 ms·

You're confusing readability with capability. Yes without Generics trying to build such a collection in Java is insanely verbose and yes very hard to follow, bu

You're confusing readability with capability. Yes without Generics trying to build such a collection in Java is insanely verbose and yes very hard to follow, but with generics, while it's less code to write to build the collection you do hit a mental Yield when you try to read that line: "Ok, this is a Map, it keys on Integers to ... another Map, that keys on Integers and points to Doubles. Ok got it, lets continue" Of course when you actually go to use this collection, you don't benefit that much (off the top of my head): Map<Integer,Map<Integer,Double>> = myEntry; myEntry.set(5, new Map<Integer, Double>(10, 30.0)); Map<Integer, Double> entry = myMap.get(5); ... etc You are constantly having to restate the types and the generics. It's this constant repetition and "compiler pleasing" that the author is complaining about.

deleted 16y ago
[deleted]
gthank 16y ago
There are two ways to avoid that kind of pain: 1. Create a new class that cleanly encapsulates what it is you're trying to do. This is often a PITA, but will probably result in the cleanest code if you use it much. 2. Leverage the little bit of type inferencing Java provides by using static factory methods to create your new collections. You could write your own, but they're often available in libraries, e.g., `Maps.newHashMap()` and friends from Guava. This isn't the best solution, but it cleans things up a bit, and would render your example something more like: Map<Integer, Map<Integer, Double>> = myEntry; // This is longer because you used an imaginary syntax in your example Map<Integer, Double> curEntry = Maps.newHashMap(); curEntry.put(10, 30.0); myEntry.set(5, curEntry);
jmount 16y ago
Readability is one of the hardest things to achieve in code, so you might as well make it easier. I admit Java is ugly- but you can locally determine what it is up to. The repetition of types is bad (been really enjoying how Scala got rid of that). But the "it is too much typing" kind of complaint is irrelevant if you have an editor or IDE that can paste, execute quick macros or add the boilerplate all by itself.

deleted 16y ago

[deleted]

gthank 16y ago

There are two ways to avoid that kind of pain: 1. Create a new class that cleanly encapsulates what it is you're trying to do. This is often a PITA, but will probably result in the cleanest code if you use it much. 2. Leverage the little bit of type inferencing Java provides by using static factory methods to create your new collections. You could write your own, but they're often available in libraries, e.g., `Maps.newHashMap()` and friends from Guava. This isn't the best solution, but it cleans things up a bit, and would render your example something more like: Map<Integer, Map<Integer, Double>> = myEntry; // This is longer because you used an imaginary syntax in your example Map<Integer, Double> curEntry = Maps.newHashMap(); curEntry.put(10, 30.0); myEntry.set(5, curEntry);

jmount 16y ago

Readability is one of the hardest things to achieve in code, so you might as well make it easier. I admit Java is ugly- but you can locally determine what it is up to. The repetition of types is bad (been really enjoying how Scala got rid of that). But the "it is too much typing" kind of complaint is irrelevant if you have an editor or IDE that can paste, execute quick macros or add the boilerplate all by itself.