Proposal: Collection Literals (original) (raw)

Reinier Zwitserloot reinier at zwitserloot.com
Tue Mar 31 08:38:55 PDT 2009

Many reasons for not just having varargs constructors on collections
API classes:

  1. constructors don't infer generics.

  2. constructors don't make immutables. Even Arrays.asList doesn't.
    This is how you make an immutable list of constants today:

Collections.unmodifiableList(Arrays.asList("foo", "bar"));

that, is, in a word, ridiculous. Even with constructor help, it woud
become:

Collections.unmodifiableList(new ArrayList("foo", "bar"));

not much help, and arguably even worse.

It would become, with Joshes proposal:

["foo", "bar"]

which makes me smile.

  1. import statements. Okay, that's a small one, but nevertheless.

  2. Implementation is often irrelevant, when the list is immutable
    anyway. Why force people to type ArrayList. For that matter, why force
    people to -read- ArrayList? It's just 'A list with no surprises, which
    is immutable'. That's easy enough to remember.

  3. varargs are fundamentally broken, though fortunately the proposal
    to address this issue is on the project coin shortlist.

--Reinier Zwitserloot

On Mar 31, 2009, at 17:14, Joshua Bloch wrote:

Kris, I think the confusion between set literals and array literals is overblown. So far as I know, the only context in which it can occur is a nested array initializer on the right hand side of an array declaration. If you want arrays, you typically want them "all the way down." So the proposed solution of banning collection literals in array initializers on the right hand side of array declarations seems like a perfect solution to this corner case.

Of course it is possible to directly use collection factories with varargs (such as Arrays.toList), but you lose the conciseness, especially for maps. Similarly, we don't need array-like access to collections: we can continue using set, get, and put. But it people want the succinctness of array-like access to collections, then they probably want the succinctness of collection literals too. As for reified generics, I'm still waiting for a code example where the proposed approach will cause trouble. Regards, Josh On Tue, Mar 31, 2009 at 7:56 AM, Kris Nuttycombe <kris.nuttycombe at gmail.com>wrote:

Given the possibility of confusion between set literals and array initializers, how much worse would it be simply to provide vararg constructors, in the various collection classes? Similarly, why not just some additional vararg factory methods in Collections that can be used to produce the immutable versions?

I realize that the syntax isn't quite as terse as what this proposal suggests, but I think it avoids the issues with reified types and would not represent a substantial deviation from the current state of the libraries. The only place where this wouldn't work is for map literals; however, if a Pair literal were introduced as has been suggested elsewhere then this problem could be easily resolved. Kris

More information about the coin-dev mailing list