No. Even the kind of generics in Java vastly increased the documentary power of the collections. Being able to write thing like Map<Integer,Map<Integer,Double>> (a very crude sparse matrix) is a great boon in readability.
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):
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.
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);
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.
He seems to go to great lengths to emphasize the visual clutter in the declaration, but then mentions nothing of the casts that are no longer needed as a result. Anecdotes != proof I know, but I can say that I have caught several typecast mismatches in code I've converted from pre-generic times to using generics.
But all that is not what the article is about, really. Say what you will about Java, whether or not it's dead or dying, etc. but I dare say that generics in and of themselves aren't causing the Java ecosystem any substantial damage.
6 comments
[ 0.19 ms ] story [ 22.0 ms ] thread"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.
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:
But all that is not what the article is about, really. Say what you will about Java, whether or not it's dead or dying, etc. but I dare say that generics in and of themselves aren't causing the Java ecosystem any substantial damage.