Proposal: Collection Literals

Reinier Zwitserloot reinier at zwitserloot.com
Tue Mar 31 09:07:25 PDT 2009


Actually, it would help creating mutable collections classes with  
initial values quite well. If the proposal is accepted:

List<String> list = new SuperExtraMegaList<String>(["foo", "bar"]);

I am assuming there will be an 'addAll' constructor, which is what  
ArrayList, LinkedList, and just about every other list, set, and map  
in java.util has. Even if it doesn't:

List<String> list = new CrazyList<String>();
list.addAll(["foo", "bar"]);

not as nice, but still nicer than what we have now, especially if your  
initial set contains 20, and not 2, items.

  --Reinier Zwitserloot



On Mar 31, 2009, at 17:57, Kris Nuttycombe wrote:

> 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<String>("foo", "bar"));
>>
>> not much help, and arguably even worse.
>>
>
> I was imagining something more along the lines of:
>
> Collections.<String>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