For further consideration, round 2

[Reinier Zwitserloot]

If "It's not in java.lang" is a valid argument, then we should get rid  
of the magic that makes java.io.Serializable work, as well as the  
foreach loops, which use java.lang.Iterable, which refers to  
java.util.Iterator, which is just not allowed in a java language  
feature, apparently.

OR, we stop worrying about package names and treat proposals based on  
their merits, instead of pointing out irrelevant distractions.

> Map<String, Integer> map = HashMap.unmodifiableMap(new
> Map.Pair<String, Integer >("foo", 123),
>         new Map.Pair<String, Integer >("bar", 456));

Just look at it. And then look at this:

	Map<String, Integer> map = {"foo": 123, "bar": 456};

Now choose which one you'd rather look at, let alone type.

> A language extension for pairs might make sense

... but list and map literals don't. Okay. Why?

How would pairs type? A new 'java.util.Pair' type, or should it be in  
java.lang, which means any existing class named Pair (and, boy, are  
there many of those!) are now in a namespace conflict, causing fun  
times for everyone that imports their own Pair class via a star import?

> But again, is there really a strong enough use case for collection
> literals in Java to justify any kind of language change?



Yes, there is. Do a code check on how many collection literals you  
make versus how often you do a list member lookup by index. In my code  
I'm looking at roughly a 50:1 ratio.


  --Reinier Zwitserloot



On 2009/20/07, at 22:09, Greg Brown wrote:

> Hi all,
>
> I just came across this thread and wanted to comment:
>
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-June/001945.html
>
> Hope I'm not too late.
>
>> 6,7 (Elvis and Other Null-Safe Operators,  Indexing access syntax for
>> Lists and Maps)
>
>> 8,9, Strings in switch, Collection Literals.
>
>
> IMO, the Elvis operator would be handy, though definitely not a must
> have. Same goes for Strings in switch statements. My main interest is
> in the other two items: "Indexing access syntax for Lists and Maps"
> and "Collection Literals".
>
> 1) Indexing access syntax for Lists and Maps
>
> It would be nice to see this feature extended to any class, not just
> List and Map. Groovy supports this by mapping the index operator to
> getAt() and putAt() - a similar approach (possibly one that maps to
> get(int)/set(int, E) and get(K)/put(K, V)) would be more flexible and
> would still work for List and Map.
>
> 2) Collection Literals
>
> I would argue that, since List, Map, and Set are not part of
> java.lang, they should not be given special language-level treatment.
> Also, I don't like the ambiguity of what type of collection is
> actually created. Finally, I'm not sure I see a strong enough use case
> here to justify a language change.
>
> Why not just add some new varargs methods to meet this need? List and
> Set would be easy:
>
> List<Integer> list = ArrayList.unmodifiableList(1, 2, 3);
> Set<String> set = HashSet.unmodifiableSet("a", "b", "c");
>
> The resulting code is fairly concise, doesn't require any language
> changes, and eliminates any ambiguity about what type of collection is
> created. Map would require a bit more effort since there is currently
> no class to represent a key/value pair, but could work something like
> this:
>
> Map<String, Integer> map = HashMap.unmodifiableMap(new
> Map.Pair<String, Integer >("foo", 123),
>         new Map.Pair<String, Integer >("bar", 456));
>
> A language extension for pairs might make sense, if Pair was defined
> in java.lang and the rules for type inference could be extended to
> support it:
>
> Map<String, Integer> map = HashMap.unmodifiableMap({"foo":123},  
> {"bar":
> 456});
>
> But again, is there really a strong enough use case for collection
> literals in Java to justify any kind of language change? If you are
> finding that you truly need collection literals, is it possible that
> Java just isn't the right language for the problem you are trying to
> solve?
>
> -Greg
>
>