Project Lambda: Java Language Specification draft

[Mark Thornton]

Osvaldo Pinali Doederlein wrote:
> Em 24/01/2010 16:45, Mark Thornton escreveu:
>   
>> Peter Levart wrote:
>>    
>>     
>>>>    #()( {1,2,3} )   // Proposed collection literal expression from Coin
>>>>
>>>>        
>>>>         
>>> Well, without parentheses the above example shows why the proposed collection literal expression
>>> syntax is inappropriate. That syntax is reserved for statements - expressions should not mess
>>> with it. Without mandatory parentheses, this is ambiguous:
>>>
>>> #() {}
>>>
>>> ...is this an expression lambda returning empty collection or a statement lambda returning void?
>>>
>>>      
>>>       
>> Unfortunately Java already has array initialisation using {}, so the
>> syntax clearly isn't reserved just for statements. I think that existing
>> use for array initialisation was one of the reasons for using {} in
>> collection literals instead of [].
>>    
>>     
>
> The collection literals proposal is already underwhelming IMHO, because 
> it boils down to sugar over the Collections.unmodifiableXxx() APIs. We 
>   
I partly agree. For lists and sets something like this

public CollectionLiterals {
    <T> public static List<T> list(T... e) {...}
}

used with static import is almost as brief. Maps though are more 
annoying to initialise. The best I can manage with existing Java

public CollectionLiterals {
public static <K,V> MapBuilder<K,V> mapOf(K key, V value) {...}
}

public static interface MapBuilder<K, V> {
        MapBuilder<K,V> and(K key, V value);
        Map<K,V> create();
}

Giving

mapOf(a,b).and(c,d) ... .create();

However I have managed a StackOverflow in javac with code like this :-(.

Now if there was a short way of creating tuples so that

public static <K,V> Map<K,V> mapOf(Map.Entry<K,V> ... entries) {}

could be used like

mapOf((a,b), (c,d), ...)

preferably without so many parentheses.


> concrete implementations for these collections. While higher-level langs 
> may contain multiple implementations of some collection and 
> automatically pick or change the optimal impl for each situation (even 
>   
Easier to do with functional style where changing the implementation, 
when a value or mapping is added or removed, presents no problem.


Mark