On Jan 8, 2009, at 11:52 AM, Eric Tschetter wrote:
I -1 this patch unless you can sufficiently explain why e.g.
- tokenData = new HashMap<String, String>(5,1);
+ tokenData = Maps.newHashMapWithExpectedSize(5);
is better readable to someone with knowledge of the standard Java
APIs
and no knowledge of Google Collections.
Is it really that hard to understand? Really? Some Junior Devs
looked at
that code and easily understood the intent.
Did those Junior Devs also understand the initial incantation?
All three understood the intent of google collections code. One knew
what the args to new HashMap meant. One knew about the constructor
arguments, but didn't know what the second parameter was used for, and
the third wasn't aware of HashMap constructors arguments.
All that this huge patch IMHO does is making the code harder to read
for no particular reasons.
There are reasons. In this case you use the factory methods to not
repeat
yourself. Consider the degenerate case:
Map<Integer, List<Map<Foo,Bar>>> = new
HashMap<Integer,List<Map<Foo,Bar>>>(5,1);
you can replace the RHS with Maps.newHashMapWithExpectedSize(5)
We are entering the realm of religious minutia here, but what is the
benefit of taking a mathematical language and replacing it with a
natural language? Sure, it makes sense for a small group of people
(i.e. internal/personal development) to create and introduce
"languages" that they find easier to understand, but when something is
being consumed by some unknown plurality, it doesn't make sense to
force that plurality to learn your way of doing things when there is a
common, accepted way of doing it that they will already know.
In math, it doesn't make sense to replace ∏ with
"multiply-all-numbers-in-the-series" and ∑ with
"sum-all-numbers-in-the-series", because the symbols are a part of the
"universal" mathematical language. People who understand math will
understand the symbols. Switching the names to
"multiply-all-numbers-in-the-series" might work well for introducing
English speakers to the idea of ∏, but it will do very little for
anyone who doesn't speak English. While it's probably true that
English permeates Java enough that anyone who can program Java has at
least some understanding of English, I don't know why replacing the
instantiation of a HashMap with a more flowing, "natural" English
method call (i.e. replacing a mathematical language with natural
language) is beneficial in an open source project.
Of course, if the object it creates isn't just a Java HashMap<...>,
then the change isn't related to language but to the actual runtime
properties of the system. My understanding, however, is that the Maps
method above is just a wrapper around "new HashMap<...>()"
Remember that the intent is to replace boilerplate code when using
Java generics. This isn't a one-for-one substitution as you describe
above. You don't repeat the type definitions on the constructor. I
agree that the 'newHashMapwithExpectedSize()' is excessively wordy,
but it's really only a small part of what's on offer.
To get a taste of why please read the series 'Coding in the small with
Google Collections' available here: http://publicobject.com/2007/09/series-recap-coding-in-small-with.html
Here's their take on the feature above:
Generics are good, but they can be really wordy!
Before:
Map<CustomerId, BillingOrderHistory> customerOrderHistoryMap
= new HashMap<CustomerId, CustomerOrderHistory>();
After:
Map<CustomerId, CustomerBillingOrderHistory> customerOrderHistoryMap
= Maps.newHashMap();
Look Ma! I don't have to specify my type parameters twice! (The
compiler figures it out through Type Inference from Assignment
Context). Maps, Sets and Lists contain factory methods to create
Collections objects.
Paul Lindner
[email protected]
