Proposal: Collection Literals (original) (raw)

Kris Nuttycombe kris.nuttycombe at gmail.com
Tue Mar 31 08:57:03 PDT 2009

On Tue, Mar 31, 2009 at 9:38 AM, Reinier Zwitserloot <reinier at zwitserloot.com> wrote:

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.

I was imagining something more along the lines of:

Collections.immutableList("foo", "bar"). Of course, this is currently possible to do as a third-party library, so if one is content with such syntax there's already a solution.

It would become, with Joshes proposal:

["foo", "bar"] which makes me smile.

Yes, however his proposal does not address the issue of simplifying the construction of mutable collections with initial contents. Of course, as the original proposal mentions one can always use anonymous inner classes (Crazybob's contraption) for this.

Kris

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

4. 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. 5. varargs are fundamentally broken, though fortunately the proposal to address this issue is on the project coin shortlist.  --Reinier Zwitserloot

More information about the coin-dev mailing list