TimurMahammadov / google-collections

Automatically exported from code.google.com/p/google-collections
Apache License 2.0
0 stars 0 forks source link

a new factory-method on Lists class #9

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hi,

I want a list index-based then I did this function:
  public static <E> ArrayList<E> newArrayList(
                  int size, Function<Integer, E> function) {
    checkNotNull(function);
    int capacity = computeArrayListCapacity(size);
    ArrayList<E> list = new ArrayList<E>(capacity);
    for (int i = 0; i < size; i++) {
        list.add(function.apply(i));
    }
    return list;
  }

Now, I can to create a list with the 1000 first natural numbers with the
following code:
List<Integer> numbers = Lists.newArrayList(1000,                          
    Functions.<Integer>identity());

What do you think about it?

Original issue reported on code.google.com by jonhnnyw...@gmail.com on 20 Oct 2007 at 2:10

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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