For further consideration, round 2

Ulf Zibis Ulf.Zibis at gmx.de
Tue Jul 21 00:56:05 PDT 2009


Am 20.07.2009 22:09, Greg Brown schrieb:
> 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

Hm, why you are thinking about a new type, we just have java.util.MapEntry?
And we have public constructors from AbstractMap.SimpleEntry and 
AbstractMap.SimpleImmutableEntry.
Language extension could map [ final {"foo":123}] to [ 
new AbstractMap.SimpleImmutableEntry<String, Integer>("foo", 123) ]
or, we even don't need the braces, so have: [ "foo":123] and [ final 
"foo":123]
The only thing, I dislike, is the 'Abstract' part of the naming.

We can't extend Map for add(MapEntry<K,V>), but we can extend HashMap 
etc., (or have new ExtendedMap interface)
HashMap<String, Integer> hm;
hm["foo"] = 123; // should work
hm["foo"] = final 123; // should put new 
AbstractMap.SimpleImmutableEntry<String, Integer>("foo", 123)
Map<String, Integer> m;
m["foo"] = 123; // compile error

Although I can live without indexing access syntax (hm.put("foo":123) is 
quite readable and smart), I much like the pair literal (better named 
'map entry literal', as semantic of 1st and 2nd element aren't equal).
It enables the opportunity for collection/array literals: {"foo":123, 
"bar":456, ...}


BTW: I would like to see:
    foo({"Hello", "World"});
for
   void <T> foo(T.. elements);
and
    String[] sa;
    sa = {"Hello", "World"};

-Ulf








More information about the coin-dev mailing list