Proposal: Collection Literals

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<String>("foo", "bar"));

not much help, and arguably even worse.

It would become, with Joshes proposal:

["foo", "bar"]

which makes me smile.

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



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