Henning,
I don't appreciate you characterizing my comments as sniping.
We've already spent a lot of time on this and I don't think any more
discussion is going to change your mind. I think that's because I and
others are making qualitative instead of quantitative arguments.
Regarding your cons:
* Replace existing java idiom with g-c static calls -- My unscientific
sample already determined that the syntax is understandable. There's
precedence for the g-c idioms -- just look at EnumSet, no constructors
there.
* Alpha nature of library -- g-c has had some interface changes (note
the 0.5 to 0.8 transition), nothing too ugly. Overall it's been very
stable, and the test coverage is among the highest I've seen.
* Static call overhead -- you can't be serious?
On Jan 11, 2009, at 11:46 AM, Henning Schmiedehausen wrote:
On Fri, Jan 9, 2009 at 18:09, Paul Lindner <[email protected]> wrote:
It's not a need, it's a want. As in:
[... personal snipe removed ...]
In the same way I (and others) want to use google-collections
because it
makes Java programming more productive. It eliminates boilerplate
code and
provides an impressive amount of functionality that improves on the
base
Java Collections Framework.
What exactly do you want Henning? Do you want to vote on whether
we use g-c
or not?
I want to discuss whether it is beneficial to use it or not. So far
I have:
Pro:
- Less typing
- Better readable
which are both human-centric arguments because the actual typing
overhead is eradicated by the compiler and not present at runtime.
Contra:
- removes a common, well known Java idiom with something that is
unique to a library
- Library does not have a proper release but a 2008-08-20 snapshot
build as its newest version.
which are maintainability arguments
- Adds a static method call at every occurrence; (most of them are not
on hot paths)
which is a technological argument
And I want to find out whether the first two really outweigh the
latter three.
IAW: I want an architectural discussion. And I want a decision whether
one should fade such a change into a code base
or just use a blanket replacement. I fully agree with the benefits of
readability that Kevin showed but I don't agree that
Map<String, Integer> foo = new HashMap<String, Integer>() should be
replaced with a g-c call.
And I want this discussion in the open, not "I work with people, we
decided, done" type discussions.
Ciao
Henning
On Jan 9, 2009, at 5:02 PM, Henning Schmiedehausen wrote:
On Wed, Jan 7, 2009 at 23:38, Paul Lindner <[email protected]> wrote:
On Jan 7, 2009, at 5:14 PM, Henning Schmiedehausen 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.
Everything needed has been said by Eric. He is smart and correct.
I stand by my -1 I would still appreciate a compelling explanation,
why this is needed.
Ciao
Henning
