Project Lambda: Java Language Specification draft

[Osvaldo Pinali Doederlein]

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 
don't get to choose the concrete types of constructed collections, we 
don't get support for modifiable collections (and as much as I like the 
OO/Functional paradigm, Java ain't there yet - we'll deal with explicit 
mutable stuff for eons to come). If I want to use the new syntax to 
initialize, say, a HashMap, I suppose I can write "new HashMap<K,V>({a: 
b, c: d})" and cross my fingers so javac will be smart enough to 
optimize this into a straight initialization of the HashMap, without 
building some temporary unmodifiable Map and then passing that to the 
HashMap(Map) constructor. I expect javac to have such optimizations, but 
even with that, the resulting syntax would be a bit less elegant than 
ideal. This proposal should consider that, differently than many 
scripting languages that have always had maps and lists as first-class 
language entities, Java has the distinct advantage of offering a very 
rich (and extensible: Apache, Google, user-provided etc.) choice of 
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 
JavaFX Script does this for its sequences), this results in some 
tradeoffs, and the Java style is avoiding these and just letting the 
user to do these choices explicitly and manually. It's also very 
frequent that I want a specific impl because it offers extended APIs or 
behaviors, e.g. 99% of the massive features from java.util.concurrent 
collections can't be used without resorting to extended 
APIs.(Collections are not even completely adherent to the Liskov 
Substitution Principle.) So, I'd like the collection-literals to allow 
me to write some thing like: HashMap{a:b, c:d}, explicitly specifying 
the concrete type (if I want that); and also: SortedMap{a:b, c:d}, where 
I don't provide a class but I provide an interface (or N interfaces? 
Serializable would come to mind...), and javac picks some concrete type 
that implements that interface and javac believes to be a good choice 
for whatever reason.

A+
Osvaldo