JEP 186: Collection Literals

[Klaus Malorny]

On 14.01.2014 20:33, Paul Benedict wrote:
> The other reason I prefer a unified syntax is so other types can
> participate in the syntax. Brian alluded to this first (kudos). I had this
> mind when I wrote my email (but didn't know such liberal uses were being
> entertained), and it would really be nice to allow such things. Then we can
> use such constructs for three-value tuples, n-value tuples, etc.
>

Hi,

originally, I did not want to interfere the expert round with my layman ideas 
any further, but I changed my mind, at least for the this next e-mail ;-). I 
hope it is thematically not too far away from Brian's desires.

Well, one could define a generic syntax that can represent at least list-style 
and map-style data sets. These are translated by compiler into calls to a 
builder interface that is somehow provided by the desired type, e.g.

List<String> list = ArrayList#["a", "b", "c"];

is translated into:

ListBuilder<ArrayList<String>> lb = Internal.magicFunction (ArrayList.class);
                          // uses information from annotations to ArrayList
                          // or whatever in order to construct
                          // ListBuilder instance

lb.start ();             // maybe with # elements to ease resource allocation
lb.add ("a");            // maybe with multi-argument methods instead
lb.add ("b");
lb.add ("c");
list = lb.getObject ();  // result must be of type ArrayList<String>

This would avoid the limitation of the literals to the Java Collection Framework.


Syntax-wise, some automatic simplifications could be applied for multi-level 
structures, e.g. a list of sets:

List<Set<Integer>> list = ArrayList#[HashSet#[1, 2, 3], [2, 3, 4], [3, 4, 5]];
                                      ^                  ^          ^
                                      0                  1          2

i.e. for the element 1, the preceding type of element 0 would be reused, which 
is HashSet, and the same applies to element 2. If no type is given at all, a 
Java specific well-defined type is used (e.g. HashSet, ArrayList, HashMap), 
derived from the type on the lhs.

As an alternative, the outer list builder (see above) could provide a 
subordinate builder if no explicit builder is defined for an element. However, 
this would likely reduce the flexibility and maybe also hard to perform some 
compile time type checks. I guess nobody would like to see e.g. an 
"OperationNotSupported" or a "ClassCastException" exception from a literal 
construct. It would also be quite intransparent to the developer who uses the 
literal.

But I have to admit that I am not really convinced of my own ideas...

Regards,

Klaus