Closed GoogleCodeExporter closed 9 years ago
Jared's counter-proposal from email:
public static <E> List<E> newList(
final int size, final Function<Integer, E> function) {
checkNotNull(function);
return new AbstractList() {
public int size() {
return size;
}
public E get(int index) {
return function.apply(index);
}
};
}
This is the approach that's consistent with the design philosophy of the
library. We
prefer to provide views over choosing a data structure for you.
However, I'm not sure why using Jared's suggested method would really be any
easier
than just writing the AbstractList implementation yourself. I'm inclined not
to take
any action on this one.
Original comment by kevin...@gmail.com
on 22 Oct 2007 at 5:41
Copying the email exchange (jonhnnyweslley's comment and my response) to the
bug :
Each approach is better in certain scenarios. If the average number of reads per
element is large, your approach has better CPU performance. If the average
number of
reads is much less than 1, my approach has better CPU performance. Your approach
returns a modifiable list, but mine requires less memory.
As a third option, the returned List could have lazy initialization,
calculating each
element the first time it's needed.
We should decide which approaches to include in the libraries.
On 10/22/07, jonhnnyweslley@gmail.com <jonhnnyweslley@gmail.com> wrote:
Hi Jared,
Really, it's not clear what's the best approach.
But I think that with my function depending the case
has a best performance, because if the function executes
a heavy processing for each time that invokes a List.get() method.
And still, allow the user to modifies the list.
Original comment by jared.l....@gmail.com
on 22 Oct 2007 at 6:06
To summarize, the original request was for a method that would let you replace
code
like this:
List<Integer> firstHundredSquares = Lists.newArrayListWithExpectedSize(100);
for (int i = 0; i < 100; i++) {
firstHundredSquares.add(i * i);
}
with
List<Integer> firstHundredSquares = Lists.newArrayList(100,
new Function<Integer, Integer>() {
@Override public Integer apply(Integer i) {
return i * i;
}
});
Because Java syntax for creating simple anonymous instances of things like
Functions
is so awful, I don't see a clear win here. You might have heard us say this
before,
but we really considered not including Function and Predicate in the open-source
library at all (and could still decide not to). They're just such a pain in
the ass.
Original comment by kevin...@gmail.com
on 31 Oct 2007 at 1:23
Original issue reported on code.google.com by
jonhnnyw...@gmail.com
on 20 Oct 2007 at 2:10