Add size() method to Immutable*.Builder

[GoogleCodeExporter]

It is sometimes be convient to know the current size of a container as I am 
building one.  For example, I have some code where I am building Lists of N 
elements from a stream of data.  In this code I have to add an extra counter to 
keep track of the number of elements I have added to the builder which is 
something the Builder is already tracking.  Another common case, is checking of 
the collection isEmpty(), so I can throw an exception.

Of couse this isn't a big burden on me, but it would be nice to have.

Original issue reported on code.google.com by d...@iq80.com on 9 Sep 2012 at 6:55

[GoogleCodeExporter]

I'd suggest using a normal mutable collection for doing this. The immutable 
collection builders' reason to exist is to allow you to do things like create a 
static final field in a single statement. In such situations, you can't check 
the size anyway. For situations where you can check the size, the builder isn't 
providing any value over a normal mutable collection, so just go ahead and use 
that.

Original comment by cgdec...@gmail.com on 9 Sep 2012 at 10:08

• Added labels: Package-Collect, Type-Addition

[GoogleCodeExporter]

In these cases, I am building an immutable collection, and am not interested in 
"accessing" the values as I'm building the collection.  I'm simply suggesting 
that a bit more information about the current state of the builder, which the 
builder already has, would make my code simpler.

If it is not something that the Guava maintainers don't thinks is generally 
useful, I understand.  This is just a suggestion.

Original comment by d...@iq80.com on 9 Sep 2012 at 11:27

[GoogleCodeExporter]

+1 for just using a mutable collection and then doing an ImmutableXXX.copyOf 
for this need.

The biggest reason I can think of for *not* supporting this feature is e.g. for 
Set or SortedSet builders that might -- or might not -- eliminate duplicates on 
the fly.  Should the size counter include duplicates, or not?

Locking ourselves into one or the other behavior seems like a very bad idea, 
especially when there's an equally simple workaround that doesn't require us to 
commit to any particular builder implementation.

Original comment by wasserman.louis on 10 Sep 2012 at 1:18

[GoogleCodeExporter]

Good point.  I didn't think of the case of duplicates in sets or maps.  Please 
close this issue.

Original comment by d...@iq80.com on 10 Sep 2012 at 1:36

[GoogleCodeExporter]

Original comment by wasserman.louis on 10 Sep 2012 at 1:39

• Changed state: WorkingAsIntended

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:13

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit