Closed GoogleCodeExporter closed 9 years ago
Indeed, for the very most common collections (ArrayList, HashSet and HashMap
only) we
do have newFooWithExpectedSize() methods.
Note that the concept of "expected size" is not exactly the same as "initial
capacity", but it's more often what you're *really* trying to express, so we
think
it's what's most useful.
Original comment by kevin...@gmail.com
on 3 Jul 2008 at 9:48
Thanks, I am clearly blind!
Must admit though... those methods are a bit of a mouthful! I suppose the
decision was made as people would expect the
integer parameter to be 'initial' rather than expected.
I would still request the parameters for 'initial' sizes... in many of my use
cases, I know exactly how big the list (or hashmap)
will be and therefore do not mean 'expected'. Your point about the difference
is well noted, however!
Original comment by Sam.Hall...@gmail.com
on 3 Jul 2008 at 10:17
I agree they're a mouthful. I'd consider maybe removing "expected" from them and
relying on the parameter names and javadoc to convey the exact meaning behind
"size".
Now in the case that you want to choose an initial capacity of 100 for your
hash set,
is there really any benefit of
Set<Thingy> thingies = Sets.newHashSetWithCapacity(100);
over
Set<Thingy> thingies = new HashSet<Thingy>(100);
? We think there isn't really, and you'd be better off using the latter.
It might be different if we had the ability to name the method just
"newHashSet", but
we can't because of overload conflicts, so it has to be something else like
"newHashSetWithCapacity" which erases any possible gains.
As well, with all that said, we only feel that the static factory methods need
to
address 95% of use cases, because having to fall back on the old-fashioned way
for
the other 5% isn't really *that* painful. It's when it pervades your entire
codebase
that it's painful.
Original comment by kevin...@gmail.com
on 3 Jul 2008 at 10:26
I was hoping that you'd use the overloaded approach... if that's not possible
then I'd consider this closed.
Good point about the overloading. I hadn't thought of it, but of course if the
left side generic is <Integer> then
the compiler is going to allow the integer as an entry!
Original comment by Sam.Hall...@gmail.com
on 3 Jul 2008 at 10:34
Original issue reported on code.google.com by
Sam.Hall...@gmail.com
on 3 Jul 2008 at 9:16