Consider creating a ImmutableCollection.Builder base class.

[GoogleCodeExporter]

An abstract ImmutableCollection.Builder base class would allow creation of 
common routines that could add() to all varieties of Builders, like so

private void addMe(ImmutableCollection.Builder<T> foo, T o) {
  foo.add(o);
}

etc..

Original issue reported on code.google.com by lind...@inuus.com on 23 Jun 2009 at 1:19

[GoogleCodeExporter]

What's the use case for that?

Original comment by jared.l....@gmail.com on 23 Jun 2009 at 4:55

[GoogleCodeExporter]

I was refactoring this code to use ImmutableSet/ImmutableList, it would be nice 
if I 
could pass in the Builder for the appropriate immutable collection..

Is there a better way to do this?

private Collection<Object> convertToCollection(JSONArray in, Collection<Object> 
out, Type type) {
     for (int i = 0, j = in.length(); i < j; ++i) {
       out.add(convertToObject(in.opt(i), type));
     }
   return out;
}

Original comment by lind...@inuus.com on 23 Jun 2009 at 5:15

[GoogleCodeExporter]

For a case like yours, I'd recommend just creating an ArrayList in your method,
returning it, and passing the result to ImmutableList/ImmutableSet.copyOf().  
The
builder classes are designed primarily for constants, not general use:

public static final ImmutableList<Color> GOOGLE_COLORS
    = new ImmutableList.Builder<Color>()
        .addAll(WEBSAFE_COLORS)
        .add(new Color(0, 191, 255))
        .build();

Specifically, there's no performance advantage to using builder.build() over
copyOf():  As currently implemented, ImmutableList.Builder and 
ImmutableSet.Builder
use an ArrayList internally and call copyOf() on it.

Original comment by cpov...@google.com on 23 Jun 2009 at 6:14

[GoogleCodeExporter]

point taken, I know that the Builder implementation uses an arraylist 
underneath..  Just 
seems like making  ImmutableXXX.Builder follow the same hierarchy as 
ImmutableXXX

Original comment by lind...@inuus.com on 23 Jun 2009 at 8:03

[GoogleCodeExporter]

Use cases or not, it does seem like the proper relationship, so I will try it 
out, and 
if it goes quietly, then, why not.

Original comment by kevin...@gmail.com on 12 Aug 2009 at 6:11

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 12 Aug 2009 at 6:12

• Changed state: Accepted
• Added labels: 1.0

[GoogleCodeExporter]

We decided we are not going to have a public ImmutableCollection.Builder class 
unless 
compelling use cases emerge.

Original comment by kevin...@gmail.com on 19 Aug 2009 at 1:31

• Changed state: WontFix

[GoogleCodeExporter]

Issue 298 has been merged into this issue.

Original comment by kevinb@google.com on 8 Dec 2009 at 5:18

[GoogleCodeExporter]

Was the use case in 298 not sufficient to make Builder public so that the Scala
builders can extend it?

Original comment by blair-ol...@orcaware.com on 8 Dec 2009 at 7:15